Starting Program Execution

To start execution of the debugged program, select Program => Run. You will then be prompted for the arguments to pass to your program. You can either select from a list of previously used arguments or enter own arguments in the text field. Afterwards, press the Run button to start execution with the selected arguments.

To run your program again, with the same arguments, select Program => Run Again or press the Run button on the command tool. You may also enter run, followed by arguments at the debugger prompt instead.

When you click on Run, your program begins to execute immediately. See Stopping, for a discussion of how to arrange for your program to stop. Once your program has stopped, you may call functions in your program to examine data. See Examining Data, for details.

If the modification time of your symbol file has changed since the last time GDB read its symbols, GDB discards its symbol table, and reads it again. When it does this, GDB and DDD try to retain your current debugger state, such as breakpoints.

• Arguments: Your program's arguments.
• Environment: Your program's environment.
• Working Directory: Your program's directory.
• Input/Output: Your program's I/O.

Node:Arguments, Next:Environment, Up:Starting Program Execution

Your Program's Arguments

The arguments to your program are specified by the arguments of the run command, as composed in Program => Run.

In GDB, the arguments are passed to a shell, which expands wildcard characters and performs redirection of I/O, and thence to your program. Your SHELL environment variable (if it exists) specifies what shell GDB uses. If you do not define SHELL, GDB uses /bin/sh.

If you use another inferior debugger, the exact semantics on how the arguments are interpreted depend on the inferior debugger you are using. Normally, the shell is used to pass the arguments, so that you may use normal conventions (such as wildcard expansion or variable substitution) in describing the arguments.

Node:Environment, Next:Working Directory, Previous:Arguments, Up:Starting Program Execution

Your Program's Environment

Your program normally inherits its environment from the inferior debugger, which again inherits it from DDD, which again inherits it from its parent process (typically the shell or desktop).

In GDB, you can use the commands set environment and unset environment to change parts of the environment that affect your program. See Your program's environment, for details.

The following environment variables are set by DDD:

• DDD
• Set to a string indicating the DDD version. By testing whether DDD is set, a debuggee (or inferior debugger) can determine whether it was invoked by DDD.
• TERM
• Set to dumb, the DDD terminal type. This is set for the inferior debugger only.²⁰
• TERMCAP
• Set to `' (none), the DDD terminal capabilities.
• PAGER
• Set to cat, the preferred DDD pager.

The inferior debugger, in turn, might also set or unset some environment variables.

Node:Working Directory, Next:Input/Output, Previous:Environment, Up:Starting Program Execution

Your Program's Working Directory

Your program normally inherits its working directory from the inferior debugger, which again inherits it from DDD, which again inherits it from its parent process (typically the shell or desktop).

You can change the working directory of the inferior debugger via File => Change Directory or via the cd command of the inferior debugger.

Node:Input/Output, Previous:Working Directory, Up:Starting Program Execution

Your Program's Input and Output

By default, the program you run under DDD does input and output to the debugger console. Normally, you can redirect your program's input and/or output using Illegal HTML tag removed : shell redirections with the arguments--that is, additional arguments like < Illegal HTML tag removed : input or > Illegal HTML tag removed : output. You can enter these shell redirections just like other arguments (see Arguments).

Warning: While input and output redirection work, you cannot use pipes to pass the output of the program you are debugging to another program; if you attempt this, DDD may wind up debugging the wrong program. See Attaching to a Process, for an alternative.

If command output is sent to the debugger console, it is impossible for DDD to distinguish between the output of the debugged program and the output of the inferior debugger.

Program output that confuses DDD includes:

• Primary debugger prompts (e.g. (gdb) , (dbx) or (ladebug) )
• Secondary debugger prompts (e.g. >)
• Confirmation prompts (e.g. (y or n) )
• Prompts for more output (e.g. Press RETURN to continue)
• Display output (e.g. $pc = 0x1234)

If your program outputs any of these strings, you may encounter problems with DDD mistaking them for debugger output. These problems can easily be avoided by redirecting program I/O, for instance to the separate execution window (see Using the Execution Window).

If the inferior debugger changes the default TTY settings, for instance through a stty command in its initialization file, DDD may also become confused. The same applies to debugged programs which change the default TTY settings.

The behavior of the debugger console can be controlled using the following resource:

Node:Using the Execution Window, Next:Attaching to a Process, Previous:Starting Program Execution, Up:Running