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:
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.