User`s guide

Chapter 6: Controlling Program Execution

SIGALRM signal to your program. Your program then enters the

alarm_handler procedure and stops. You can then single-step through the

procedure and observe execution.

Debugging a program that attempts to catch signals can be awkward if you

also catch the signal in dbx. For example, if your program wants to catch

SIGFPEs and you issue the command:

(dbx) catch sigfpe

Then, after dbx catches the signal, you must execute the command:

(dbx) ignore sigfpe

This prevents dbx from catching the signal again when you resume execution

of your program.

If you want to catch further instances of that signal in your program, you

must regain dbx control (the best way is to set a breakpoint before executing

the cont) to re-execute the catch sigfpe command.

Stopping at System Calls

Because system calls are part of the operating system and their source is

generally not available for debugging purposes, you cannot set breakpoints

in system calls using the same method that you use for your program’s

procedures. Instead, dbx provides the syscall command to allow you to stop

your program when it executes system calls. With the syscall command you

can catch (breakpoint) system calls either at the entry to the system call or at

the return from the system call.

The syntax of the syscall command is:

syscall catch {call | return} {system_call | all}

Sets a breakpoint to stop execution upon entering (call) or

returning from (return) the speciﬁed system call. Note that

you can set dbx to catch both the call and the return of a

system call.

If you use the keyword all rather than giving a speciﬁc

system call, dbx catches all system calls.