()", and show the file and
line number where the initialization is taking place.
It is not possible to breakpoint in static initialization code
that is executed in the course of loading a shared librray.
The source window should display the file that contains the main()
routine. The source files window lists the files used by the program.
Selecting a line from the source files window will display that file in
the main debugger window.
When the program is stopped, selecting different call stack frames
will bring up the source window that contains the execution point of
the selected function.
See section on specifying alternate source file directories under
Debugging Environment.
The debugger will, by default, stop when an exception is being thrown.
It can also stop when the exception is caught. Automatic breakpoint at
throw and catch can be set in the Debug...Options menu.
When the debugger stops the condition of the throw and the object
being caught can be examined through the Expression Window.
The Debug..Options... menu item allows you to modify various parameters
of the debugging session:
- Program Pathname: the name of the executable
- Program Arguments: the argument string to be used when running
the program
- Working Directory: the directory where the program will be executed.
- Source Directories: a list of source file path prefixes to be used
in locating source files. This allows you to debug the executable
in a different location from where it was compiled and still be
able to find the source files.
- C++: Enable/Disable program breakpoint on exception throw/catch
- Fonts: Fonts size and type used in various windows
- Misc: Enable full or relative path names in source file list
Some aspects of the debug environment are preserved from one
kdb invocation to the next. This information is saved in a user
preferences file .KDBPrefs, in your home directory. The preserved
informations includes the following:
- The position of the main window (on platforms which support that).
- The position and visibility of the Expressions, Source Code,
Source Files, Stack, and Functions windows.
- The locations of the draggable dividers in the Stack and Expression
windows.
- The positions of all breakpoints.
- Whether to use full pathnames or just filenames in the Source Files
window.
- Whether to break when an exception is thrown.
- Whether to break when an exception is caught.
- The fonts used for menus, GUI items (dialog items), the source code,
the status bar, buttons, the Source Files list, and line numbers.
- For each program which has been run, the program arguments, working
directory, and source files directories list.
The top-level debugger window has 4 main sub-windows:
- Source File List Window containing a list of source files used by
the program. Clicking on a line in this window brings up that
source file in the Source Window
- Source Window displaying a source file. This window is used to
set breakpoints
- Call Frame Window displaying the call stack at the point at which
the program was stopped
- Expression Window displaying the current value of expressions
entered by the user.
In addition, a Function Name Window displays the names
of functions found in the program (not including shared libraries).
The subwindows can be resized and rearranged to meet the needs of a
particular debugging session. The window ordering is preserved from
one invocation of the debugger to the next.
A default horizontal or vertical tiling of the windows can be
selected from the Windows menu. The initial gui state is
a horizontal tiling.
Specific windows can also be enabled or disabled using the Windows menu.
The fonts used in different display windows can be controlled through
the Debug...Options menu. If a part of the display is hard to see, you
should change the font for that window to get one that displays better
on your monitor.
The source files window lists the files used by the program.
Clicking on a line in this window brings up that source file in
the Source Window.
This window may display the full file path or just the file
name, depending on the configuration selected under Edit..Options..Misc.
On some platforms the file path is relative to the current directory, on
other platforms the path is absolute. When the path is relative, alternate
search paths can be given under the Edit..Options..Program menu item.
(See Debugging Environment)
Initially, the source window should display the file that contains
the main() routine. A blue
arrow indicates the current execution location in the
program. Outlined blue arrows indicate
function call sites leading to the current execution location.
There are several actions that switch files displayed and automatically
position the source window to the appropriate line:
- when the program stops, either at a breakpoint or for any
other reason, the current execution location is displayed
- when the program is stopped, selecting a file in the
Source File List Window will display that file
- when the program is stopped, selecting a call stack frame
in the Call Frame Window will display the current execution
location in that function
- selecting a function in the Function Name Window and
choosing "Show Source" will display the selected function
in the Source Window
The call frame stack is displayed whenever the program is stopped. Each
line should correspond to one function on the call stack. Clicking on a
call frame line will display that call site in the source window.
A button to the left of a call frame line means that the function has
local variables that can be displayed. Clicking on this button will
display the local variables. All local variables in the function are
displayed, even if they belong to a nested lexical scope.
The local variable display works like the general expression window
described below. All expressions are initially "locked" to call stack
context where they belong.
The Expression Window displays the current value of variables and
expressions in the program. It is updated whenever the program stops.
You can adjust the width of the fields in the display by dragging
the field separators.
If a round button appears to the left of the expression, the expression
can be expanded to show class members or dereferenced pointers. This
allows you to navigate down a data structure without typing new expressions.
Expressions can be locked to a specific call frame or float in the
current context. The green "U" and red "L" indicate the current state
of an expression. A locked expression is always interpreted as if the
locked stack frame were on the top of the stack. A floating or unlocked
expression is interpreted in the current context where the program is
stopped.
Functions can be called from the expression window. At present
only non-overloaded non-virtual functions can be called. Any output
from a called function will appear in the window that started the
debugger, together with all other program output. When calling a
global function use the unmangled name and enter the function call
as you would in the current program context.
The interface supports a collection of useful operators. These
operators include arithmetic, post/pre-inc/decrement, pointer
deference (*), address-of, direct and indirect member selection, cast,
function call and subscript operators. A more complete list of operator
limitations listed in the known problems section.
The Function Name Window displays a list of functions defined in the
application. The "Show Source" button will display the source to the
function in the Source Window. The "Set Breakpoint" will set a breakpoint
at the beginning of the function.
This window is now shown until requested. To display the
Functions Window, click menu option Windows..Show_Functions_Window.
The window is initially empty, because it could contain a very large
number of very long function names. As you type in the name of the
function you are looking for, the functions that match the prefix you
have entered will appear in the window. You can then click on the
complete function name to select it.
Automatic startup of debugger and gui on separate machines
Starting with version 1.1e, the kdb command supports debugging
on a remote host with the graphic display on your local host.
The debug session is started by a command on the remote host.
Requirements for remote debugging:
- kdb must be installed on both hosts. A valid license
is only required for the remote host where the
application is being debugged.
- On the local host where the gui will appear, kdb must
be on the default search path. Usually a symbolic
link from /usr/local/bin/kdb to wherever kdb is installed
is sufficient for this, or adjustment of your default
path to include the kdb/bin/ directory.
- The systems involved must support rsh (remote shell)
from the remote host to the local host. Unless special
security barriers are in place, this usually works.
To start a remote debug session with a local gui display enter
this command on the remote system.
kdb -gh {gui_host} {program}.
where {gui_host} is your local host, and {program}
is the program to be debugged.
Manually startup of debugger and gui on separate machines
On the remote machine where the debugging is to take place, start the
debugger kernel with the command
kdb_kernel
If the bin/ directory for the KAI C++ Debugger is not on your path,
you may need to specify the full path to the executable kdb_kernel.
This command will print a message saying it is waiting for a connection
(from a graphic user interface), and stating the host and
port number on which it is expecting to connect.
On the local machine where you want the gui to run, start the
gui with this command
kdb -guionly -dh host -dp port progname
where host and port are the
host name and port number given by the kdb_kernel command, above, and
progname is the name of the executable to
debugged.
Under Linux with version 1.1b, it is possible to view Fortran
routines called from a C/C++ program. The Fortran source will be
displayed, allowing you to set breakpoints, step through the program,
etc.. The expression window will use C/C++ syntax to access the
Fortran data, so, for instance, C array syntax must be used to
access Fortran arrays.
Under normal operating conditions, there should be no need
to specify any command line options to kdb.
The following command line options are provided in case particular
situations require them.
If your environment requires you to set these
one or more of these options on a regular basis, we would appreciate
it if you would contact c++support@kai.com
and explain your situation so that we could understand why the
options are necessary for you.
| |
-prog <pathname>
|
|
The path of the program to debug. This can also be set with the
Edit...Options menu entry. |
| |
-pid <process_id>
|
|
A process to which the debugger should attach. See notes below
on interaction with -prog. Attaching to a process can
also be done after the GUI has started, with the Debug..Attach
menu entry. |
|
-dh <host_name>
|
|
The host name of the machine where the debugger kernel will be
running. This is the machine where the application runs.
Normally this option is only used in conjunction with -guionly |
|
-dp <port_number>
|
|
The port number used to communicate between the GUI and the debugger.
The port number is normally selected automatically. |
|
-gh <gui_host>
|
|
The host name where the gui should be run when
remote debugging. |
|
-guidir <pathname>
|
|
The path to an alternate graphic user interface |
|
-guionly
|
|
Starts only the graphic interface for the debugger. Normally only
used for remote debugging |
|
-debugdir <pathname>
|
|
The path to an alternate debugger kernel |
|
|
|
|
Any command line argument other than the above is assumed to be the program
name. Thus the -prog keyword is optional. The command
kdb prog_name
is equivalent to
kdb -prog prog_name
When -prog and -pid are both specified, the debugger does
not verify that the executable matches the actual process executing. When
using -pid alone, the debugger attempts to find the executable file
but may not be successful. -pid can generally be used alone (without
-prog) when the debugger is run in the same directory where the
executable file exists.
- General restrictions
- Debugging core files is not supported.
- The program to be debugged should be C/C++ compiled with KCC, without
optimization, and with debug information (i.e. use the +K0 option).
Other programs may (or may not) produce unexpected results.
- Expression Operators.
- Relational, logical, assignment, sizeof, bitwise,
ternary and coma operators are not implemented. Overloaded operators
are not recognized.
- Function call limitations.
- Functions that have breakpoints set, and
functions that exit the program should not be called.
- Functions with
more than 8 parameters can not be called.
- Functions with args or return values that are aggregates or floating
point types can not be called.
- Display windows
- Debugger window may take a few seconds to appear when debugger starts.
- Java windows may not refresh as required, parts of windows may be blank.
Copyright © 1999 by Kuck & Associates, Inc. All rights reserved.
