User`s guide

Continuing Execution After a Machine-Level Breakpoint

To avoid this problem, use the stopi in command:

dbx() stopi in functionx

If you really want to use stopi at, a safe alternative is to disassemblefunctionx

and put the breakpoint after the gp_prolog. For more information on

gp_prolog, see the MIPSpro Assembly Language Programmer’s Guide.

The tracei at, wheni at, and conti at commands described in the following

sections also follow this pattern. Use their “in” versions to ensure that the

function breakpoint is hit.

Continuing Execution After a Machine-Level Breakpoint

The conti command continues executing assembly code after a breakpoint.

As with the cont command, if your program stops because dbx catches a

signal intended for your program, then dbx sends that signal to your

program when you continue execution. You can also explicitly send a signal

to your program when you continue execution. Signal processing and

sending signals to your program is discussed in “Using Signal Processing”

on page 73.

The syntax of the conti command is:

conti [signal] Continues execution with the current instruction.

conti [signal] {at | to} address

Sets a temporary breakpoint at the speciﬁed address, then

resumes execution with the current instruction. When your

program reaches the breakpoint at address, dbx stops your

program and deletes the temporary breakpoint.

conti [signal] in procedure

Sets a temporary breakpoint to stop execution upon

entering the speciﬁed procedure, then resumes execution

with the current instruction. When your program reaches

the breakpoint in procedure, dbx stops your program and

deletes the temporary breakpoint.

See also “Linking With DSOs” on page 90 for a description on using the

conti in and conti at commands with DSOs.