Previous Next Contents Index Doc Set Home


Controlling Program Execution

4

This chapter describes how to run, attach to, continue, and rerun a program in dbx, and how to single-step through lines of program code.

This chapter is organized into the following sections:

Basic Concepts

page 35

Running a Program in dbx

page 36

Executing a Program

page 38

Continuing a Program

page 39

Using Ctrl+C to Stop a Process

page 40

Command Reference

page 41

Basic Concepts

The commands used for running, stepping, and continuing (run, rerun, next, step, and cont) are called process control commands.

Used together with the event management commands described later in this manual, you can control the run-time behavior of a program as it executes under dbx.

Running a Program in dbx

When you first load a program into dbx, dbx visits the program's "main" block (main for C, C++, and Fortran 90, MAIN for FORTRAN 77 and program for Pascal). dbx waits for you to issue further commands; you can visit code or use event management commands.

You may choose to set breakpoints in the program before running it. When ready, use the run command to start program execution.

To run a program in dbx without arguments, type:

(dbx) run

To run a program with command line arguments, type:

(dbx) run -o <my_input_file

To redirect a program, type:

(dbx) run [arguments][input_file | > output_file]

Output from the run command overwrites an existing file even if you have set noclobber for the shell in which you are running dbx.

The run command by itself restarts the program using the previous arguments and redirection. The rerun command restarts the program and clears the original arguments and redirection.

Attaching dbx to a Running Process

You may need to debug a program that is already running. For example, you may want to debug a running server and you do not want to stop or kill it; or a program may be looping indefinitely and you would like to examine it under the control of dbx without killing it. You can attach dbx to a running program by using the program's pid number as an argument to the dbx start-up command.

Once you have debugged the program, you can then use the detach command to take the program out from under the control of dbx without terminating the process.

If you quit dbx after having attached it to a running process, dbx implicitly detaches before terminating.

To attach dbx to a program that is running independently of dbx:

1. If dbx is already running, type:

(dbx) debug program_name process_ID

You can substitute a -(dash) for the program_name; dbx automatically finds the program associated with the pid and loads it.

2. If dbx is not running, start dbx with the process_ID (pid) number as an argument:

% dbx program_name process_ID

After you have attached dbx to a program, the program stops executing. You can examine it as you normally would any program loaded into dbx. You can use any event management or process control command to debug it.

Detaching a Process from dbx

When you have finished debugging the program, use the detach command to detach dbx from the program. The program then resumes running independently of dbx.

To detach a process from running under the control of dbx, use the dbx detach command: 

(dbx) detach

Executing a Program

dbx supports two basic single-step commands: next and step, plus a variant of step, called step up. Both next and step let the program execute one source line before stopping again.

If the line executed contains a function call, next executes that call and returns from it ("steps over" the call). step stops at the first line in a called function.

step up returns the program to the caller function after you have stepped into a function.

You can specify the number of single steps. The dbx commands step and next accept a number argument that lets you specify an exact number of source lines to execute before stopping. The default is 1.

To single step a specified number of lines of code, use the dbx commands next or step followed by the number of lines [n] of code you want executed:

(dbx) step n

pop pops the top frame off the stack and adjusts the frame pointer and the stack pointer accordingly. The pop command also changes the program counter to the beginning of the source line at the call site.

Calling a Function

When a program is stopped, you can call a function using the dbx call command, which accepts values for the parameters that must be passed to the called function.

To call a procedure, type the name of the function and supply its parameters:

(dbx) call change_glyph(1,3)

Notice that while the parameters are optional, you must type in the parentheses after the function_name, for example:

(dbx) call type_vehicle()

If the source file in which the function is defined was compiled with the -g flag, or if the prototype declaration is visible at the current scope, dbx checks the number and type of arguments and issues an error message if there is a mismatch. Otherwise, dbx does not check the number of parameters.

By default, after every call command, dbx automatically calls fflush(stdout) to ensure that any information stored in the I/O buffer is printed. A user may call a function explicitly, using the call command, or implicitly, by evaluating an expression containing function calls or using a conditional modifier such as stop in glyph -if animate(). To turn off automatic flushing, you can set the dbxenv output_autoflush to off.

For C++, dbx handles default arguments and function overloading. Automatic resolution of the C++ overloaded functions is done if possible. If any ambiguity remains (for example, functions not compiled with -g), dbx shows a list of the overloaded names.

When you use call, dbx behaves "next-like," returning from the called function. However, if the program hits a breakpoint in the called function, dbx stops the program at the breakpoint and emits the message. If you now issue a where command, the stack trace shows that the call originated from dbx command level.

If you continue execution, the call returns normally. If you attempt to kill, run, rerun, or debug, the command aborts as dbx tries to recover from the nested interpreters. You can then re-issue the command.

Continuing a Program

To continue a program, just use the cont command:

(dbx) cont

The cont command has a variant, cont at line_number, which allows you to specify a line other than the current program location line at which to resume program execution. This allows you to skip over one or more lines of code that you know are causing problems, without having to recompile.

To continue a program at a specified line, enter the cont at line_number command in the command pane:

(dbx) cont at 124

The line number is evaluated relative to the file in which the program is stopped; the line number given must be within the scope of the function.

A useful application of cont at is in conjunction with an assign command. Using cont at line_number with assign, you can avoid executing a line of code that contains a call to a function that may be incorrectly computing the value of some variable.

To resume program execution at a specific line:

1. Use assign to give the variable a correct value.

2. Use cont at line_number to skip the line that contains the function call that would have computed the value incorrectly.

Assume that a program is stopped at line 123. Line 123 calls a function, how_fast() that computes incorrectly a variable, speed. You know what the value of speed should be, so you assign a value to speed. Then you continue program execution at line 124, skipping the call to how_fast().

(dbx) assign speed = 180; cont at 124;

If you use this command with a when breakpoint command, the program skips the call to how_fast() each time the program attempts to execute line 123.

(dbx) when at 123 { assign speed = 180; cont at 124;}

Using Ctrl+C to Stop a Process

You can stop a process running in dbx using Ctrl+C (^C). When you stop a process using ^C, dbx ignores the ^C, but the child process sees it as a SIGINT and stops. You can then inspect the process as if it had been stopped by a breakpoint.

To resume execution after stopping a program with ^C, use cont.You do not need to use the cont optional modifier, sig signal_name, to resume execution. The cont command resumes the child process after cancelling the pending signal.

Command Reference

run

Use the run command by itself to execute the program with the current arguments:

run

To begin executing the program with new arguments:

run args

rerun

To re-execute the program with no arguments:

rerun

next

The next command with no arguments steps one line stepping over calls:

next

To step n lines skipping over calls:

next n

To deliver the given signal while executing the next command:

next ... -sig sig

The dbxenv variable step_events controls whether breakpoints are enabled during a step.

To step the given thread:

next tid

To step the given LWP:

next lwpid

This will not implicitly resume all LWPs when skipping a function. When an explicit tid or lwpid is given, the deadlock avoidance measure of the generic next is defeated.

With multithreaded programs, when a function call is skipped over, all LWPs are implicitly resumed for the duration of that function call in order to avoid deadlock. Non-active threads cannot be stepped.

cont

Use the cont command to continue execution. In a multithreaded process, all threads are resumed.

cont

To continue execution at line line. id is optional. 

cont line id




cont ... -sig signo

To continue execution with the signal signo:

To continue execution from a specific thread or LWP: 

cont ... id

To continue execution and follow a forked process: 

cont ... -follow parent|child

step

The step command with no arguments steps one line stepping into calls:

step

To step n lines stepping into calls:

step n

To step n lines stepping into calls and out of the current function:

step up n

To deliver the given signal while executing the step command:

step ... -sig sig

The dbxenv variable step_events controls whether breakpoints are enabled during a step.

To step the given thread (step up does not apply):

step ... tid

To step the given LWP:

step ... lwpid

This will not implicitly resume all LWPs when skipping a function. When an explicit tid or lwpid is given, the deadlock avoidance measure of the generic step is defeated.

With multithreaded programs, when a function call is skipped over, all LWPs are implicitly resumed for the duration of that function call in order to avoid deadlock. Non-active threads cannot be stepped.

debug

The debug command prints the name and arguments of the program being debugged.

debug

To begin debugging a program with no process or core:

debug program

To begin debugging a program with corefile core:

debug -c core program

-or-

debug program core

To begin debugging a program with process ID pid:

debug -p pid program

-or-

debug program pid

To force the loading of a corefile; even if it doesn't match:

debug -f ...

To retain all display, trace, when, and stop commands. If no -r option is given, an implicit delete all and undisplay 0 is performed.

debug -r

To start debugging a program even if the program name begins with a dash:

debug [options] -- prog

detach

The detach command detaches dbx from the target, and cancels any pending signals:

detach

To detach while forwarding the given signal:

detach -sig sig



Previous Next Contents Index Doc Set Home