Debugging with GDB: Optimized Code

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

# 11. Debugging Optimized Code

Almost all compilers support optimization. With optimization disabled, the compiler generates assembly code that corresponds directly to your source code, in a simplistic way. As the compiler applies more powerful optimizations, the generated assembly code diverges from your original source code. With help from debugging information generated by the compiler, GDB can map from the running program back to constructs from your original source.

GDB is more accurate with optimization disabled. If you can recompile without optimization, it is easier to follow the progress of your program during debugging. But, there are many cases where you may need to debug an optimized version.

When you debug a program compiled with ``-g -O'`, remember that the optimizer has rearranged your code; the debugger shows you what is really there. Do not be too surprised when the execution path does not exactly match your source file! An extreme example: if you define a variable, but never use it, GDB never sees that variable--because the compiler optimizes it out of existence.

Some things do not work as well with ``-g -O'` as with just ``-g'`, particularly on machines with instruction scheduling. If in doubt, recompile with ``-g'` alone, and if this fixes the problem, please report it to us as a bug (including a test case!). See section 10.3 Program Variables, for more information about debugging optimized code.

> 11.1 Inline Functions |  | How GDB presents inlining
> 11.2 Tail Call Frames |  | GDB analysis of jumps to functions

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

## 11.1 Inline Functions

Inlining is an optimization that inserts a copy of the function body directly at each call site, instead of jumping to a shared routine. GDB displays inlined functions just like non-inlined functions. They appear in backtraces. You can view their arguments and local variables, step into them with `step`, skip them with `next`, and escape from them with `finish`. You can check whether a function was inlined by using the `info frame` command.

For GDB to support inlined functions, the compiler must record information about inlining in the debug information --- GCC using the DWARF 2 format does this, and several other compilers do also. GDB only supports inlined functions when using DWARF 2. Versions of GCC before 4.1 do not emit two required attributes (``DW_AT_call_file'` and ``DW_AT_call_line'`); GDB does not display inlined function calls with earlier versions of GCC. It instead displays the arguments and local variables of inlined functions as local variables in the caller.

The body of an inlined function is directly included at its call site; unlike a non-inlined function, there are no instructions devoted to the call. GDB still pretends that the call site and the start of the inlined function are different instructions. Stepping to the call site shows the call site, and then stepping again shows the first line of the inlined function, even though no additional instructions are executed.

This makes source-level debugging much clearer; you can see both the context of the call and then the effect of the call. Only stepping by a single instruction using `stepi` or `nexti` does not do this; single instruction steps always show the inlined body.

There are some ways that GDB does not pretend that inlined function calls are the same as normal calls:

- Setting breakpoints at the call site of an inlined function may not work, because the call site does not contain any code. GDB may incorrectly move the breakpoint to the next line of the enclosing function, after the call. This limitation will be removed in a future version of GDB; until then, set a breakpoint on an earlier line or inside the inlined function instead.

- GDB cannot locate the return value of inlined calls after using the `finish` command. This is a limitation of compiler-generated debugging information; after `finish`, you can step to the next line and print a variable where your program stored the return value.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

## 11.2 Tail Call Frames

Function `B` can call function `C` in its very last statement. In unoptimized compilation the call of `C` is immediately followed by return instruction at the end of `B` code. Optimizing compiler may replace the call and return in function `B` into one jump to function `C` instead. Such use of a jump instruction is called tail call.

During execution of function `C`, there will be no indication in the function call stack frames that it was tail-called from `B`. If function `A` regularly calls function `B` which tail-calls function `C`, then GDB will see `A` as the caller of `C`. However, in some cases GDB can determine that `C` was tail-called from `B`, and it will then create fictitious call frame for that, with the return address set up as if `B` called `C` normally.

This functionality is currently supported only by DWARF 2 debugging format and the compiler has to produce ``DW_TAG_GNU_call_site'` tags. With GCC, you need to specify ``-O -g'` during compilation, to get this information.

`info frame` command (see section 8.5 Information About a Frame) will indicate the tail call frame kind by text `tail call frame` such as in this sample GDB output:

    (gdb) x/i $pc - 2
       0x40066b <b(int, double)+11>: jmp 0x400640 <c(int, double)>
    (gdb) info frame
    Stack level 1, frame at 0x7fffffffda30:
     rip = 0x40066d in b (amd64-entry-value.cc:59); saved rip 0x4004c5
     tail call frame, caller of frame at 0x7fffffffda30
     source language c++.
     Arglist at unknown address.
     Locals at unknown address, Previous frame's sp is 0x7fffffffda30

The detection of all the possible code path executions can find them ambiguous. There is no execution history stored (possible 6. Running programs backward is never used for this purpose) and the last known caller could have reached the known callee by multiple different jump sequences. In such case GDB still tries to show at least all the unambiguous top tail callers and all the unambiguous bottom tail calees, if any.

`set debug entry-values`
  When set to on, enables printing of analysis messages for both frame argument values at function entry and tail calls. It will show all the possible valid tail calls code paths it has considered. It will also print the intersection of them with the final unambiguous (possibly partial or even empty) code path result.

`show debug entry-values`
  Show the current state of analysis messages printing for both frame argument values at function entry and tail calls.

The analysis messages for tail calls can for example show why the virtual tail call frame for function `c` has not been recognized (due to the indirect reference by variable `x`):

    static void __attribute__((noinline, noclone)) c (void);
    void (*x) (void) = c;
    static void __attribute__((noinline, noclone)) a (void) { x++; }
    static void __attribute__((noinline, noclone)) c (void) { a (); }
    int main (void) { x (); return 0; }

    Breakpoint 1, DW_OP_GNU_entry_value resolving cannot find
    DW_TAG_GNU_call_site 0x40039a in main
    a () at t.c:3
    3	static void __attribute__((noinline, noclone)) a (void) { x++; }
    (gdb) bt
    #0  a () at t.c:3
    #1  0x000000000040039a in main () at t.c:5

Another possibility is an ambiguous virtual tail call frames resolution:

    int i;
    static void __attribute__((noinline, noclone)) f (void) { i++; }
    static void __attribute__((noinline, noclone)) e (void) { f (); }
    static void __attribute__((noinline, noclone)) d (void) { f (); }
    static void __attribute__((noinline, noclone)) c (void) { d (); }
    static void __attribute__((noinline, noclone)) b (void)
    { if (i) c (); else e (); }
    static void __attribute__((noinline, noclone)) a (void) { b (); }
    int main (void) { a (); return 0; }

    tailcall: initial: 0x4004d2(a) 0x4004ce(b) 0x4004b2(c) 0x4004a2(d)
    tailcall: compare: 0x4004d2(a) 0x4004cc(b) 0x400492(e)
    tailcall: reduced: 0x4004d2(a) |
    (gdb) bt
    #0  f () at t.c:2
    #1  0x00000000004004d2 in a () at t.c:8
    #2  0x0000000000400395 in main () at t.c:9

Frames #0 and #2 are real, #1 is a virtual tail call frame. The code can have possible execution paths `mainabcdf` or `mainabef`, GDB cannot find which one from the inferior state.

`initial:` state shows some random possible calling sequence GDB has found. It then finds another possible calling sequcen - that one is prefixed by `compare:`. The non-ambiguous intersection of these two is printed as the `reduced:` calling sequence. That one could have many futher `compare:` and `reduced:` statements as long as there remain any non-ambiguous sequence entries.

For the frame of function `b` in both cases there are different possible `$pc` values (`0x4004cc` or `0x4004ce`), therefore this frame is also ambigous. The only non-ambiguous frame is the one for function `a`, therefore this one is displayed to the user while the ambiguous frames are omitted.

There can be also reasons why printing of frame argument values at function entry may fail:

    int v;
    static void __attribute__((noinline, noclone)) c (int i) { v++; }
    static void __attribute__((noinline, noclone)) a (int i);
    static void __attribute__((noinline, noclone)) b (int i) { a (i); }
    static void __attribute__((noinline, noclone)) a (int i)
    { if (i) b (i - 1); else c (0); }
    int main (void) { a (5); return 0; }

    (gdb) bt
    #0  c (i=i@entry=0) at t.c:2
    #1  0x0000000000400428 in a (DW_OP_GNU_entry_value resolving has found
    function "a" at 0x400420 can call itself via tail calls
    i=<optimized out>) at t.c:6
    #2  0x000000000040036e in main () at t.c:7

GDB cannot find out from the inferior state if and how many times did function `a` call itself (via function `b`) as these calls would be tail calls. Such tail calls would modify thue `i` variable, therefore GDB cannot be sure the value it knows would be right - GDB prints `<optimized out>` instead.

[ << ] | [ >> ] |  |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

This document was generated by GNAT Mailserver on April, 17 2014 using texi2html