TOC PREV NEXT INDEX DOC LIST MASTER INDEX




More on Debugging of Inline Expansions

For Ada, the debugger supports the debugging of inline expansions. Inline expansions of subprogram calls occur when the OPTIMIZATION_LEVEL compiler switch is greater than zero. See the description of pragma Inline in the Appendix F chapter of the Ada Compiler Reference Guide for details.

For C/C++, the debugger supports the debugging of inline expansions. Inline expansions of function calls occur for functions declared with the inline specifier.

It is possible to step into inline expansions and step over inline expansions. After an inline expansion is entered, for example, by stepping into it, it is possible to display the parameters of the inline expansion (C++ only) and to set breakpoints in the expansion.

Inline frames in the debugger's call stack display are marked with a + character immediately after the frame number. Thus you can navigate up and down through inline expansion frames. Inline frames do not correspond to an actual hardware frame in the program call stack. They are logical frames that simulate the existence of a real frame for the inline, i.e., as if the inline is called with a normal call instruction. An inline frame shares all the hardware characteristics of the next lower non-inline frame, i.e., it has the same PC, FP, and SP register values.

The debugger supports the debugging of inline expansions with no call site code (hereafter referred to as NCSC inlines). An example of an NCSC inline is a call to a parameterless procedure or function. No parameter binding code is generated, so the first instruction generated is due to a source line in the inline body. With optimized code, even calls to subprograms with parameters can be NCSC inlines.

The first instruction of an NCSC inline is, in effect, associated with multiple source lines, that is, the line that causes the code to generate in the inline body and all the call site lines. Potentially, more than one call site line exists for nested calls (e.g., A calls B who calls C who has the first instruction).

The debugger supports setting breakpoints at NCSC inline call sites. Similarly, it supports stepping to such lines without stepping into the inline. At such a call site, step over the inline call or step into it. To do the latter, the debugger simulates the step into. That is, your context changes to the inline context, but the program is not actually physically stepped, i.e., the PC does not change.

A breakpoint associated with multiple source lines is announced at the line where the breakpoint is originally set. The debugger's breakpoint display lists all lines associated with an inline breakpoint. A + character marks the line where the breakpoint is announced. Breakpoint marks are displayed at all lines associated with an inline breakpoint.

Note: The stepping support for NCSC inlines is based on heuristics that fail in some situations. However, they work in most common cases. In the worst case, you are inside an inline when you wanted to be at the call site (or vice versa). Stepping out of an inline can step several inline frames down (e.g. last line in A calls B, last line in B calls C, step from last line of C goes to A's caller). Similarly, an Execution > Run Returned (or bd) command from an inline frame may break several inline frames down.


Rational Software Corporation 
http://www.rational.com
support@rational.com
techpubs@rational.com
Copyright © 1993-2001, Rational Software Corporation. All rights reserved.
TOC PREV NEXT INDEX DOC LIST MASTER INDEX TECHNOTES APEX TIPS