DDD is a graphical front-end for GDB and other command-line debuggers.
This is the First Edition of Debugging with DDD, 15 January, 2004, for DDD Version 3.3.9.
Copyright © 2004 Universität des Saarlandes
Lehrstuhl Softwaretechnik
Postfach 15 11 50
66041 Saarbrücken
GERMANY
Distributed by
Free Software Foundation, Inc.
59 Temple Place - Suite 330
Boston, MA 02111-1307
USA
DDD and this manual are available via the DDD WWW page.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License"; See Documentation License, for details.
Send questions, comments, suggestions, etc. to ddd@gnu.org.
Send bug reports to bug-ddd@gnu.org.
The purpose of a debugger such as DDD is to allow you to see what is going on "inside" another program while it executes--or what another program was doing at the moment it crashed.
DDD can do four main kinds of things (plus other things in support of these) to help you catch bugs in the act:
Technically speaking, DDD is a front-end to a command-line debugger (called inferior debugger, because it lies at the layer beneath DDD). DDD supports the following inferior debuggers:
See Choosing an Inferior Debugger, for choosing the appropriate inferior debugger. See Sample Session, for getting a first impression of DDD.
This manual comes in several formats:
info program,
or from
DDD via Help => DDD
Reference.
The DDD source distribution
ddd-3.3.9.tar.gz contains this manual as
pre-formatted info files; you can also download them from
the DDD WWW
page.
The DDD source distribution
ddd-3.3.9.tar.gz contains this manual as
pre-formatted PostScript file; you can also download it from
the DDD WWW
page.
The DDD source distribution
ddd-3.3.9.tar.gz contains this manual as
pre-formatted PDF file; you can also download it from
the DDD WWW
page.
A pre-formatted HTML version of this manual comes
in a separate DDD package
ddd-3.3.9-html-manual.tar.gz; you can browse
and download it via
the DDD WWW
page.
The manual itself is written in TeXinfo format; its source code
ddd.texi is contained in the DDD source
distribution
ddd-3.3.9.tar.gz.
The picture sources come in a separate package
ddd-3.3.9-pics.tar.gz; you need this package
only if you want to re-create the PostScript, HTML, or PDF versions.
~/.ddd/init Help File => Open Program argc - 1 -g $ (gdb) _ Here's an example. break location
is a typed command
at the (gdb) prompt; the metasyntactic variable
location would be replaced by the
actual location. _ is the cursor position after entering
the command.
(gdb) break location
Breakpoint number at location
(gdb) _
DDD is free; this means that everyone is free to use it and free to redistribute it on a free basis. DDD is not in the public domain; it is copyrighted and there are restrictions on its distribution, but these restrictions are designed to permit everything that a good cooperating citizen would want to do. What is not allowed is to try to prevent others from further sharing any version of DDD that they might get from you. The precise conditions are found in the GNU General Public License that comes with DDD; See License, for details.
The easiest way to get a copy of DDD is from someone else who has it. You need not ask for permission to do so, or tell any one else; just copy it.
If you have access to the Internet, you can get the latest version
of
DDD from the anonymous FTP server ftp.gnu.org
in the
directory /gnu/ddd. This should contain the following
files:
ddd-version.tar.gz ddd-version-html-manual.tar.gz
ddd-version-pics.tar.gz DDD can also be found at numerous other archive sites
around the
world; check the file ANNOUNCE in a DDD
distribution for
the latest known list.
Dorothea Lütkehaus and Andreas Zeller were the original authors
of
DDD. Many others have contributed to its development.
The
files ChangeLog and THANKS in the DDD
distribution
approximates a blow-by-blow account.
The history of DDD is a story of code recycling. The oldest parts of DDD were written in 1990, when Andreas Zeller designed VSL, a box-based visual structure language for visualizing data and program structures. The VSL interpreter and the Box library became part of Andreas' Diploma Thesis, a graphical syntax editor based on the Programming System Generator PSG.
In 1992, the VSL and Box libraries were recycled for the NORA project. For NORA, an experimental inference-based software development tool set, Andreas wrote a graph editor (based on VSL and the Box libraries) and facilities for inter-process knowledge exchange. Based on these tools, Dorothea Lütkehaus (now Dorothea Krabiell) realized DDD as her Diploma Thesis, 1994.
The original DDD had no source window; this was added by Dorothea during the winter of 1994-1995. In the first quarter of 1995, finally, Andreas completed DDD by adding command and execution windows, extensions for DBX and remote debugging as well as configuration support for several architectures. Since then, Andreas has further maintained and extended DDD, based on the comments and suggestions of several DDD users around the world. See the comments in the DDD source for details.
Major DDD events:
You can use this manual at your leisure to read all about DDD. However, a handful of features are enough to get started using the debugger. This chapter illustrates those features.
The sample program sample.c (see Sample Program) exhibits the
following bug. Normally, sample should sort and print its
arguments numerically, as in the following example:
$ ./sample 8 7 5 4 1 3
1 3 4 5 7 8
$ _
However, with certain arguments, this goes wrong:
$ ./sample 8000 7000 5000 1000 4000
1000 1913 4000 5000 7000
$ _
Although the output is sorted and contains the right number of
arguments, some arguments are missing and replaced by bogus numbers;
here, 8000 is missing and replaced by
1913.3
Let us use DDD to see what is going on. First, you
must compile
sample.c for debugging (see Compiling for Debugging),
giving
the -g flag while compiling:
$ gcc -g -o sample sample.c
$ _
Now, you can invoke DDD (see Invocation)
on the
sample executable:
$ ddd sample
After a few seconds, DDD comes up. The Source
Window
contains the source of your debugged program; use the Scroll Bar
to scroll through the file.
The Debugger Console (at the bottom) contains DDD version information as well as a GDB prompt.4
GNU DDD Version 3.3.9, by Dorothea Lütkehaus and Andreas Zeller.
Copyright © 1995-1999 Technische Universität Braunschweig, Germany.
Copyright © 1999-2001 Universität Passau, Germany.
Copyright © 2001-2004 Universität des Saarlandes, Germany.
Reading symbols from sample...done.
(gdb) _
The first thing to do now is to place a Breakpoint
(see Breakpoints), making sample
stop at a location you are
interested in. Click on the blank space left to the initialization of
a. The Argument field (): now
contains the location
(sample.c:31). Now, click on Break to create
a breakpoint
at the location in (). You see a little red stop sign
appear in
line 31.
The next thing to do is to actually execute the program,
such that
you can examine its behavior (see Running).
Select Program
=> Run to execute the program; the Run Program
dialog
appears.
In Run with Arguments, you can now enter arguments for
the
sample program. Enter the arguments resulting in erroneous
behavior here--that is, 8000 7000 5000 1000 4000. Click
on
Run to start execution with the arguments you just
entered.
GDB now starts sample. Execution stops
after a few moments as
the breakpoint is reached. This is reported in the debugger console.
(gdb) break sample.c:31
Breakpoint 1 at 0x8048666: file sample.c, line 31.
(gdb) run 8000 7000 5000 1000 4000
Starting program: sample 8000 7000 5000 1000 4000
Breakpoint 1, main (argc=6, argv=0xbffff918) at sample.c:31
(gdb) _
The current execution line is indicated by a green arrow.
=> a = (int *)malloc((argc - 1) * sizeof(int));
You can now examine the variable values. To examine a simple
variable,
you can simply move the mouse pointer on its name and leave it there.
After a second, a small window with the variable value pops up
(see Value Tips). Try this with argc
to see its value
(6). The local variable a is not yet
initialized; you'll
probably see 0x0 or some other invalid pointer value.
To execute the current line, click on the Next button
on the
command tool. The arrow advances to the following line. Now, point
again on a to see that the value has changed and that a
has actually been initialized.
To examine the individual values of the a array, enter
a[0] in the argument field (you can clear it beforehand by
clicking on ():) and then click on the Print
button. This
prints the current value of () in the debugger console
(see Printing Values). In our case,
you'll get
(gdb) print a[0]
$1 = 0
(gdb) _
or some other value (note that a has only been
allocated, but the
contents have not yet been initialized).
To see all members of a at once, you must use a
special GDB
operator. Since a has been allocated dynamically, GDB
does not
know its size; you must specify it explicitly using the @
operator (see Array Slices). Enter a[0]@(argc
- 1) in the
argument field and click on the Print button. You get the
first
argc - 1 elements of a, or
(gdb) print a[0]@(argc - 1)
$2 = {0, 0, 0, 0, 0}
(gdb) _
Rather than using Print at each stop to see the
current value of
a, you can also display a, such
that its is
automatically displayed. With a[0]@(argc - 1) still being
shown
in the argument field, click on Display. The contents of
a are now shown in a new window, the Data Window.
Click on
Rotate to rotate the array horizontally.
Now comes the assignment of a's members:
=> for (i = 0; i < argc - 1; i++)
a[i] = atoi(argv[i + 1]);
You can now click on Next and Next again
to see how the
individual members of a are being assigned. Changed
members are
highlighted.
To resume execution of the loop, use the Until button.
This
makes GDB execute the program until a line greater than
the current is
reached. Click on Until until you end at the call of
shell_sort in
=> shell_sort(a, argc);
At this point, a's contents should be 8000 7000
5000 1000
4000. Click again on Next to step over the call to
shell_sort. DDD ends in
=> for (i = 0; i < argc - 1; i++)
printf("%d ", a[i]);
and you see that after shell_sort has finished, the
contents of
a are 1000, 1913, 4000, 5000, 7000--that is,
shell_sort has somehow garbled the contents of a.
To find out what has happened, execute the program once again. This
time, you do not skip through the initialization, but jump directly
into
the shell_sort call. Delete the old breakpoint by
selecting it
and clicking on Clear. Then, create a new breakpoint in
line 35
before the call to shell_sort. To execute the program
once
again, select Program => Run Again.
Once more, DDD ends up before the call to shell_sort:
=> shell_sort(a, argc);
This time, you want to examine closer what shell_sort
is doing. Click on Step to step into the call to shell_sort.
This
leaves your program in the first executable line, or
=> int h = 1;
while the debugger console tells us the function just entered:
(gdb) step
shell_sort (a=0x8049878, size=6) at sample.c:9
(gdb) _
This output that shows the function where sample is
now suspended
(and its arguments) is called a stack frame display. It
shows a
summary of the stack. You can use Status => Backtrace
to
see where you are in the stack as a whole; selecting a line (or
clicking
on Up and Down) will let you move through
the stack. Note
how the a display disappears when its frame is left.
Let us now check whether shell_sort's arguments are
correct. After returning to the lowest frame, enter a[0]@size
in the
argument field and click on Print:
(gdb) print a[0] @ size
$4 = {8000, 7000, 5000, 1000, 4000, 1913}
(gdb) _
Surprise! Where does this additional value 1913 come
from? The
answer is simple: The array size as passed in size to
shell_sort is too large by one--1913
is a bogus
value which happens to reside in memory after a. And this
last
value is being sorted in as well.
To see whether this is actually the problem cause, you can now
assign
the correct value to size (see Assignment).
Select
size in the source code and click on Set. A
dialog pops
up where you can edit the variable value.
Change the value of size to 5 and click
on OK. Then, click on Finish to resume
execution of the
shell_sort function:
(gdb) set variable size = 5
(gdb) finish
Run till exit from #0 shell_sort (a=0x8049878, size=5) at sample.c:9
0x80486ed in main (argc=6, argv=0xbffff918) at sample.c:35
(gdb) _
Success! The a display now contains the correct values
1000, 4000, 5000, 7000, 8000.
You can verify that these values are actually printed to standard
output
by further executing the program. Click on Cont to
continue
execution.
(gdb) cont
1000 4000 5000 7000 8000
Program exited normally.
(gdb) _
The message Program exited normally. is from GDB;
it indicates
that the sample program has finished executing.
Having found the problem cause, you can now fix the source code.
Click
on Edit to edit sample.c, and change the
line
shell_sort(a, argc);
to the correct invocation
shell_sort(a, argc - 1);
You can now recompile sample
$ gcc -g -o sample sample.c
$ _
and verify (via Program => Run Again) that sample
works fine now.
(gdb) run
`sample' has changed; re-reading symbols.
Reading in symbols...done.
Starting program: sample 8000 7000 5000 1000 4000
1000 4000 5000 7000 8000
Program exited normally.
(gdb) _
All is done; the program works fine now. You can end this DDD
session with Program => Exit or Ctrl+Q.
Here's the source sample.c of the sample program.
/* sample.c -- Sample C program to be debugged with DDD */
#include <stdio.h>
#include <stdlib.h>
static void shell_sort(int a[], int size)
{
int i, j;
int h = 1;
do {
h = h * 3 + 1;
} while (h <= size);
do {
h /= 3;
for (i = h; i < size; i++)
{
int v = a[i];
for (j = i; j >= h && a[j - h] > v; j -= h)
a[j] = a[j - h];
if (i != j)
a[j] = v;
}
} while (h != 1);
}
int main(int argc, char *argv[])
{
int *a;
int i;
a = (int *)malloc((argc - 1) * sizeof(int));
for (i = 0; i < argc - 1; i++)
a[i] = atoi(argv[i + 1]);
shell_sort(a, argc);
for (i = 0; i < argc - 1; i++)
printf("%d ", a[i]);
printf("\n");
free(a);
return 0;
}
This chapter discusses how to start DDD, and how to get out of it. The essentials are:
Normally, you can run DDD by invoking the program
ddd.
You can also run DDD with a variety of arguments and options, to specify more of your debugging environment at the outset.
The most usual way to start DDD is with one argument, specifying an executable program:
ddd program
If you use GDB, DBX, Ladebug, or XDB as inferior debuggers, you can also start with both an executable program and a core file specified:
ddd program core
You can, instead, specify a process ID as a second argument, if you want to debug a running process:
ddd program 1234
would attach DDD to process 1234
(unless you also have a file
named 1234; DDD does check for a core
file first).
You can further control DDD by invoking it with specific options. To get a list of DDD options, invoke DDD as
ddd --help
Most important are the options to specify the inferior debugger (see Choosing an Inferior Debugger), but you can also customize several aspects of DDD upon invocation (see Options).
DDD also understands the usual X options such as -display
or -geometry. See X Options,
for details.
All arguments and options that are not understood by DDD
are
passed to the inferior debugger; See Inferior Debugger Options,
for a
survey. To pass an option to the inferior debugger that conflicts with
an X option, or with a DDD option listed here, use the
--debugger option (see Options).
The most frequently required options are those to choose a specific inferior debugger.
Normally, the inferior debugger is determined by the program to analyze:
Use
ddd --jdb program
ddd --pydb program
ddd --perl program
ddd --bash program
ddd --interpreter='path-to-debugger-bash --debugger' program
to run DDD with JDB, PYDB, Perl, or Bash as an inferior debugger.
Use
ddd --gdb program
ddd --wdb program
ddd --dbx program
ddd --ladebug program
ddd --xdb program
to run DDD with GDB, WDB, DBX, Ladebug, or XDB as inferior debugger.
If you invoke DDD without any of these options, but give a program to analyze, then DDD will automatically determine the inferior debugger:
See Customizing Debugger Interaction, for more details on determining the inferior debugger.
You can further control how DDD starts up using the
following
options. All options may be abbreviated, as long as they are
unambiguous; single dashes - instead of double dashes --
may also be used. Almost all options control a specific DDD
resource or resource class (see Customizing).
--attach-windows Giving this option is equivalent to setting the DDD
Separate resource class to off. See Window Layout, for
details.
--attach-source-window Giving this option is equivalent to setting the DDD
separateSourceWindow resource to off.
See Window Layout, for details.
--attach-data-window Giving this option is equivalent to setting the DDD
separateDataWindow resource to off. See Window Layout,
for details.
--automatic-debugger Giving this option is equivalent to setting the DDD
autoDebugger resource to on. See Customizing Debugger
Interaction, for details.
--button-tips Giving this option is equivalent to setting the DDD
buttonTips resource to on. See Customizing Help, for
details.
--configuration Giving this option is equivalent to setting the DDD
showConfiguration resource to on. See Diagnostics, for
details.
--check-configuration Giving this option is equivalent to setting the DDD
checkConfiguration resource to on. See Diagnostics,
for details.
--data-window Giving this option is equivalent to setting the DDD
openDataWindow resource to on. See Toggling Windows,
for details.
--dbx Giving this option is equivalent to setting the DDD
debugger resource to dbx. See Customizing Debugger
Interaction, for details.
--debugger namegdb, wdb,
dbx, xdb, jdb, pydb,
or
perl).
This option can also be used to pass options to the inferior
debugger
that would otherwise conflict with DDD options. For
instance,
to pass the option -d directory
to XDB, use:
ddd --debugger "xdb -d directory"
If you use the --debugger option, be sure that the
type of
inferior debugger is specified as well. That is, use one of the options
--gdb, --dbx, --xdb, --jdb,
--pydb, or --perl (unless the default
setting works
fine).
Giving this option is equivalent to setting the DDD
debuggerCommand resource to name. See Customizing Debugger
Interaction, for details.
--debugger-console Giving this option is equivalent to setting the DDD
openDebuggerConsole resource to on. See Toggling Windows, for details.
--disassemble --no-disassemble
option, below.
Giving this option is equivalent to setting the DDD
disassemble resource to on. See Customizing Source,
for details.
--exec-window Giving this option is equivalent to setting the DDD
separateExecWindow resource to on. See Customizing the
Execution Window, for details.
--font fontname-fn fontnameGiving this option is equivalent to setting the DDD
defaultFont resource to fontname. See Customizing Fonts, for details.
--fonts Giving this option is equivalent to setting the DDD
showFonts resource to on. See Diagnostics, for
details.
--fontsize size--fontsize 120.
Giving this option is equivalent to setting the DDD
FontSize resource class to size. See Customizing Fonts, for details.
--fullname -f -fullname
format
suitable for debugger front-ends. By default, both the debugger console
and source window are disabled. See TTY mode,
for a discussion.
Giving this option is equivalent to setting the DDD
TTYMode resource class to on. See TTY mode, for
details.
--gdb Giving this option is equivalent to setting the DDD
debugger resource to gdb. See Customizing Debugger
Interaction,
for details.
--glyphs --no-glyphs option, below.
Giving this option is equivalent to setting the DDD
displayGlyphs resource to on. See Customizing Source,
for details.
--help -h -? Giving this option is equivalent to setting the DDD
showInvocation resource to on. See Diagnostics, for
details.
--host hostname--host username@hostname--login option
is not used,
use username as remote user name. See Remote Debugger, for
details.
Giving this option is equivalent to setting the DDD
debuggerHost resource to hostname. See Remote Debugger,
for details.
--jdb Giving this option is equivalent to setting the DDD
debugger resource to gdb. See Customizing Debugger
Interaction,
for details.
--ladebug Giving this option is equivalent to setting the DDD
debugger resource to ladebug. See Customizing Debugger
Interaction, for details.
--lesstif-hacks --lesstif-version 999. Deprecated.
Giving this option is equivalent to setting the DDD
lessTifVersion resource to 999. See LessTif, for
details.
--lesstif-version versionGiving this option is equivalent to setting the DDD
lessTifVersion resource to version. See LessTif, for
details.
--license Giving this option is equivalent to setting the DDD
showLicense resource to on. See Diagnostics, for
details.
--login username-l usernameGiving this option is equivalent to setting the DDD
debuggerHostLogin resource to username.
See Remote Debugger, for details.
--maintenance Maintenance menu with options
for debugging
DDD. See Maintenance
Menu, for details.
Giving this option is equivalent to setting the DDD
maintenance resource to on. See Maintenance Menu, for
details.
--manual Giving this option is equivalent to setting the DDD
showManual resource to on. See Diagnostics, for
details.
--news Giving this option is equivalent to setting the DDD
showNews resource to on. See Diagnostics, for details.
--no-button-tips Giving this option is equivalent to setting the DDD
buttonTips resource to off. See Customizing Help, for
details.
--no-data-window Giving this option is equivalent to setting the DDD
openDataWindow resource to off. See Toggling Windows,
for details.
--no-debugger-console Giving this option is equivalent to setting the DDD
openDebuggerConsole resource to off. See
Toggling Windows, for details.
--no-disassemble Giving this option is equivalent to setting the DDD
disassemble resource to off. See Customizing Source,
for details.
--no-exec-window Giving this option is equivalent to setting the DDD
separateExecWindow resource to off. See Customizing the
Execution Window, for details.
--no-glyphs Giving this option is equivalent to setting the DDD
displayGlyphs resource to off. See Customizing Source,
for details.
--no-lesstif-hacks --lesstif-version 1000. Deprecated.
Giving this option is equivalent to setting the DDD
lessTifVersion resource to 1000. See LessTif, for
details.
--no-maintenance Maintenance menu with
options for
debugging DDD. This is the default. See Maintenance Menu,
for details.
Giving this option is equivalent to setting the DDD
maintenance resource to off. See Maintenance Menu, for
details.
--no-source-window Giving this option is equivalent to setting the DDD
openSourceWindow resource to off. See Toggling Windows, for details.
--no-value-tips Giving this option is equivalent to setting the DDD
valueTips resource to off. See Value Tips, for
details.
--nw --perl Giving this option is equivalent to setting the DDD
debugger resource to perl. See Customizing Debugger
Interaction,
for details.
--pydb Giving this option is equivalent to setting the DDD
debugger resource to pydb. See Customizing Debugger
Interaction,
for details.
--panned-graph-editor --scrolled-graph-editor, below.
Giving this option is equivalent to setting the DDD
pannedGraphEditor resource to on. See Display Resources, for details.
--play-log log-file ddd --play-log log-file
invokes DDD as inferior debugger, simulating the inferior debugger given in log-file (see below). This is useful for debugging DDD.
Giving this option is equivalent to setting the DDD
playLog resource to on. See Customizing Debugger
Interaction, for
details.
--PLAY log-file~/.ddd/log file as generated by some previous
DDD session (see Logging).
When a command is entered, scan
log-file for this command and re-issue the logged reply;
if the
command is not found, do nothing. This is used by the --play
option. --rhost hostname--rhost username@hostname--login
option is not used, use username as remote user name. See Remote Debugger, for details.
Giving this option is equivalent to setting the DDD
debuggerRHost resource to hostname. See Remote Debugger, for details.
--scrolled-graph-editor --panned-graph-editor, above.
Giving this option is equivalent to setting the DDD
pannedGraphEditor resource to off. See Display Resources, for details.
--separate-windows --separate --attach options, above.
Giving this option is equivalent to setting the DDD
Separate resource class to off. See Window Layout, for
details.
--session sessionGiving this option is equivalent to setting the DDD
session resource to session. See Resuming Sessions, for
details.
--source-window Giving this option is equivalent to setting the DDD
openSourceWindow resource to on. See Toggling Windows,
for details.
--status-at-bottom Giving this option is equivalent to setting the DDD
statusAtBottom resource to on. See Window Layout, for
details.
--status-at-top Giving this option is equivalent to setting the DDD
statusAtBottom resource to off. See Window Layout, for
details.
--sync-debugger Giving this option is equivalent to setting the DDD
synchronousDebugger resource to on. See Customizing Debugger
Interaction, for details.
--toolbars-at-bottom Giving this option is equivalent to setting the DDD
toolbarsAtBottom resource to on. See Window Layout,
for details.
--toolbars-at-top Giving this option is equivalent to setting the DDD
toolbarsAtBottom resource to off. See Window Layout,
for details.
--trace --trace is not specified, this information is written
into
~/.ddd/log (~ stands for your home
directory),
such that you can also do a post-mortem debugging. See Logging, for
details about logging.
Giving this option is equivalent to setting the DDD
trace
resource to on. See Diagnostics,
for details.
--tty -t Giving this option is equivalent to setting the DDD
ttyMode resource to on. See TTY mode, for details.
--value-tips Giving this option is equivalent to setting the DDD
valueTips resource to on. See Value Tips, for details.
--version -v Giving this option is equivalent to setting the DDD
showVersion resource to on. See Diagnostics, for
details.
--vsl-library libraryGiving this option is equivalent to setting the DDD
vslLibrary
resource to library. See VSL
Resources, for details.
--vsl-path pathGiving this option is equivalent to setting the DDD
vslPath
resource to path. See VSL
Resources, for details.
--vsl-help --wdb Giving this option is equivalent to setting the DDD
debugger resource to wdb. See Customizing Debugger
Interaction, for details.
--xdb Giving this option is equivalent to setting the DDD
debugger resource to xdb. See Customizing Debugger
Interaction, for details.
DDD also understands the following X options. Note
that these
options only take a single dash -.
-display displayDISPLAY environment variable. -geometry geometry-iconic -name name-selectionTimeout timeout-title name-xrm resourcestringAll options that DDD does not recognize are passed to the inferior debugger. This section lists the most useful options of the different inferior debuggers supported by DDD. In case these options do not work as expected, please lookup the appropriate reference.
These GDB options are useful when using DDD
with GDB as inferior
debugger. Single dashes - instead of double dashes --
may
also be used.
-b baudrate--cd dir--command file--core corefile--directory dir-d dir--exec execfile--mapped --nx -n .gdbinit file. --readnow --se file--symbols symfileSee Invoking GDB, for further options that can be used with GDB.
DBX variants differ widely in their options, so we cannot give a list here. Check out the dbx(1) and ladebug(1) manual pages.
These XDB options are useful when using DDD with XDB as inferior debugger.
-d dir-P process-id-l library-l
ALL means always pre-load shared library information. -S num-s Further options can be found in the xdb(1) manual page.
The following JDB options are useful when using DDD with JDB (from JDK 1.2) as inferior debugger.
-attach address-listen address-listenany -launch run
command
These JDB options are forwarded to the debuggee:
-verbose[:class|gc|jni] -v -Dname=value-classpath path-X optionThe following JDB options are useful when using DDD with JDB (from JDK 1.1) as inferior debugger.
-host hostname-password psswd-debug)
These JDB options are forwarded to the debuggee:
-verbose -v -debug -noasyncgc -verbosegc -noclassgc -checksource -cs -ss number-oss number-ms number-mx number-Dname=value-classpath path-prof -prof:file./java.prof. If file
is given,
write the data to ./file-verify -verifyremote -noverify -dbgtrace Further options can be found in the JDB documentation.
For a list of useful PYDB options, check out the PYDB documentation.
The most important Perl option to use with DDD is -w;
it
enables several important warnings. For further options, see the
perlrun(1) manual page.
If you have the proper bash installed, the option needed to specify
debugging support is --debugger. (If your bash doesn't
understand this option you need to pick up a version of bash that does
from http://bashdb.sourceforge.net.)
If you have multiple DDD instances running, they share common preferences and history files. This means that changes applied to one instance may get lost when being overwritten by the other instance. DDD has two means to protect you against unwanted losses. The first means is an automatic reloading of changed options, controlled by the following resource (see Customizing):
| checkOptions (class CheckOptions) | Resource |
Every n seconds, where n is the value
of this resource,
DDD checks whether the options file has changed.
Default is
30, which means that every 30 seconds, DDD
checks for the
options file. Setting this resource to 0 disables
checking for
changed option files. |
Normally, automatic reloading of options should already suffice. If
you
need stronger protection, DDD also provides a warning
against
multiple instances. This warning is disabled by default, If you want to
be warned about multiple DDD invocations sharing the
same
preferences and history files, enable Edit => Preferences
=> Warn if Multiple DDD Instances are
Running.
This setting is tied to the following resource (see Customizing):
| warnIfLocked (class WarnIfLocked) | Resource |
Whether to warn if multiple DDD instances are
running
(on) or not (off, default). |
If you are bothered by X warnings, you can suppress them by setting
Edit => Preferences => General => Suppress X
warnings.
This setting is tied to the following resource (see Customizing):
| suppressWarnings (class SuppressWarnings) | Resource |
If on, X warnings are suppressed. This is
sometimes useful for executables that were built on a machine with a
different X or M*tif configuration. By default, this is
off. |
To exit DDD, select File => Exit.
You may also
type the quit command at the debugger prompt or press
<Ctrl+Q>. GDB and XDB also accept
the q command or an
end-of-file character (usually <Ctrl+D>). Closing the last
DDD window will also exit DDD.
An interrupt (<ESC> or Interrupt) does not exit
from
DDD, but rather terminates the action of any debugger
command
that is in progress and returns to the debugger command level. It is
safe to type the interrupt character at any time because the debugger
does not allow it to take effect until a time when it is safe.
In case an ordinary interrupt does not succeed, you can also use an
abort (<Ctrl+\> or Abort), which sends a SIGABRT
signal to the inferior debugger. Use this in emergencies only; the
inferior debugger may be left inconsistent or even exit after a
SIGABRT signal.
As a last resort (if DDD hangs, for example), you
may also
interrupt DDD itself using an interrupt signal (SIGINT).
This can be done by typing the interrupt character (usually
<Ctrl+C>) in the shell DDD was started from, or
by using the
UNIX kill command. An interrupt signal
interrupts any
DDD action; the inferior debugger is interrupted as
well. Since
this interrupt signal can result in internal inconsistencies, use this
as a last resort in emergencies only; save your work as soon as
possible
and restart DDD.
If you want to interrupt your current DDD session, you can save the entire the entire DDD state as session on disk and resume later.
To save a session, select File => Save Session As.
You will
be asked for a symbolic session name session.
If your program is running (see Running), or if you have opened a core file (see Opening Core Dumps), DDD can also include a core file in the session such that the debuggee data will be restored when re-opening it. To get a core file, DDD typically must kill the debuggee. This means that you cannot resume program execution after saving a session. Depending on your architecture, other options for getting a core file may also be available.
Including a core dump is necessary for restoring memory contents and
the
current execution position. To include a core dump, enable
Include Core Dump.
After clicking on Save, the session is saved in
~/.ddd/sessions/session.
Here's a list of the items whose state is saved in a session:
After saving the current state as a session, the session becomes active. This means that DDD state will be saved as session defaults:
~/.ddd/sessions/session/init
instead of
~/.ddd/init. See Saving
Options, for details. ~/.ddd/sessions/session/history
instead of
~/.ddd/history. See Command
History, for details. To make the current session inactive, open the default session
named [None]. See Resuming
Sessions, for details on opening
sessions.
To resume a previously saved session, select File => Open
Session and choose a session name from the list. After clicking
on
Open, the entire DDD state will be
restored from the
given session.
The session named [None] is the default session
which is
active when starting DDD. To save options for default
sessions,
choose the default session before exiting DDD. See Saving Options, for details.
If a the restored session includes a core dump, the program being debugged will be in the same state at the time the session was saved; in particular, you can examine the program data. However, you will not be able to resume program execution since the process and its environment (open files, resources, etc.) no longer exist. However, you can restart the program, re-using the restored breakpoints and data displays.
Opening sessions also restores command definitions, buttons, display shortcuts and the source tab width. This way, you can maintain a different set of definitions for each session.
You can also specify a session to open when starting DDD. To invoke DDD with a session session, use
ddd --session session
There is also a shortcut that opens the session session and invokes the inferior debugger on an executable named session (in case session cannot be opened):
ddd =session
There is no need to give further command-line options when restarting a session, as they will be overridden by the options saved in the session.
You can also use an X session manager such as xsm to
save and
restore DDD sessions.7
When
being shut down by a session manager, DDD saves its
state under
the name specified by the session manager; resuming the X session makes
DDD reload its saved state.
To delete sessions that are no longer needed, select File
=> Open Session or File => Save Session.
Select
the sessions you want to delete and click on Delete.
The default session [None] cannot be deleted.
You can change the place where DDD saves its
sessions by setting
the environment variable DDD_SESSIONS to the name of a
directory. Default is ~/.ddd/sessions/.
Where applicable, DDD supports a gcore
command to obtain
core files of the running program. You can enter its path via
Edit => Preferences => Helpers => Get Core
File. Leave the value empty if you have no gcore
or similar
command.
This setting is tied to the following resource (see Customizing):
| getCoreCommand (class GetCoreCommand) | Resource |
A command to get a core dump of a running process (typically,
gcore) @FILE@ is replaced by the base
name of the file
to create; @PID@ is replaced by the process id. The
output
must be written to @FILE@.@PID@.
Leave the value empty if you have no |
You can have each of DDD, the inferior debugger, and the debugged program run on different machines.
You can run DDD on a remote host, using your current host as X display. On the remote host, invoke DDD as
ddd -display display
where display is the name of the X server to connect to
(for
instance, hostname:0.0, where hostname
is your host).
Instead of specifying -display display,
you can also set
the DISPLAY environment variable to display.
In order to run the inferior debugger on a remote host, you need
remsh (called rsh on BSD systems) access on
the remote
host.
To run the debugger on a remote host hostname, invoke DDD as
ddd --host hostname remote-program
If your remote username differs from the local username, use
ddd --host hostname --login username remote-program
or
ddd --host username@hostname remote-program
instead.
There are a few caveats in remote mode:
--rhost option instead of --host.
This
will invoke the remote debugger via an interactive shell on the remote
host, which may lead to better results.
Note: using --rhost, DDD invokes
the inferior debugger as
soon as a shell prompt appears. The first output on the remote host
ending in a space character or > and not followed by a
newline is
assumed to be a shell prompt. If necessary, adjust your shell prompt on
the remote host.
xterm
terminal
emulator on the remote host, giving your current DISPLAY
environment variable as address. If the remote host cannot invoke
xterm, or does not have access to your X display,
start
DDD with the --no-exec-window option.
The program
input/output will then go through the DDD debugger
console.