Debugging with GDB Manual HP WDB v6.3 (5900-2180, August 2012)

Debug foo(), use the finish command to exit from the first top-level call, (foo()), execute
the steplast command to step into the next top-level call, (bar()). The following example
illustrates the use of steplast command:
(gdb)10 foo( bar() ) + bar( foo() ) (gdb) sl Use the steplast (sl) command to step
14.29 Getting information from a non-debug executable
You can get some information about the arguments passed to the functions displayed in the stack
trace in a non-debug, optimized executable.
When GDB has no debug information; it does not know where the arguments are located or even
the type of the arguments. GDB cannot infer this in an optimized, non-debug executable.
However, for integer arguments you can and the first few parameters for the top-of- stack frame
by looking at the registers. On PA-RISC systems, the first parameter will be in $r26, the second
in $r25, and so on. On IPF systems, the first few parameters will be in $gr32 and $gr33.
14.30 Debugging optimized code
HP WDB supports debugging of optimized code (compiled with both -g and -O) for HP aC++, HP
ANSI C and HP WDB for HP Itanium.
The following commands evaluate the name of a function and hence are affected by the optimization
level of the program being debugged (in particular, due to inlining):
• break
• call
• clear
• disassem
• list
The following commands evaluate an expression referring to variables in the user pro- gram and
hence, are affected by the optimization level of the program being debugged:
• break
• call
• cond
• jump
• return
• print
• set <var>
• watch
• whatis x
NOTE: The break and call commands involve evaluation of both the name of a function and
an expression.
The following commands are also affected by the optimization level of the program being debugged:
• backtrace
• display
• down
• finish
14.29 Getting information from a non-debug executable 179