10

We all know that inline functions can make debugging trickier, as they can be elided from stack traces etc. But suppose I want to call an inline function from within gdb, and I know its name and its arguments. I think I should be able to do that, but I get this:

Cannot evaluate function -- may be inlined

I used nm to list the symbols in the shared library I'm using, and found that the functions I want to call are not in there. No big surprise. What I'd like is a way to generate visible definitions of these inline functions. I have access to the header files which contain the inline definitions currently, but I can't really modify those headers. Perhaps there's some way to tell the compiler to emit definitions of all the inline functions it sees in a translation unit? Or some other trick that can make it easier to call and inspect the results of inline functions in gdb?

I'm using GCC 4.7.2 and GDB 7.5.1 on Linux. And I can't really switch to a non-optimized build because I'm debugging core dumps from production (in development I would just turn off optimization, then things are easier).

John Zwinck
  • 239,568
  • 38
  • 324
  • 436
  • Note. It might be preferred to only create object file and load them in gdb at debugging time to call it, rather than include the whole thing into the production executable which will make it (a little...) bigger. – user202729 Dec 07 '21 at 05:56
  • See also [c++ - Cannot evaluate function -- may be inlined - Stack Overflow](https://stackoverflow.com/questions/22163730/cannot-evaluate-function-may-be-inlined?noredirect=1&lq=1) – user202729 Dec 07 '21 at 06:09

2 Answers2

10

One way to get the compiler to generate a callable version of an inline function is to include code that takes the address of the function. There is also an option you can give to gcc. From the gcc documentation on inline functions：

When a function is both inline and static, if all calls to the function are integrated into the caller, and the function's address is never used, then the function's own assembler code is never referenced. In this case, GCC does not actually output assembler code for the function, unless you specify the option -fkeep-inline-functions.

DarkTrick
  • 2,447
  • 1
  • 21
  • 39
Mark Plotnick
  • 9,598
  • 1
  • 24
  • 40
  • 1
    I have a lot of inline functions that I want to preserve, so didn't want to need to explicitly take the address of each one. So I like your `gcc -fkeep-inline-functions` suggestion a lot. And it works! But on the other hand it makes my executable 50% larger (the number of visible symbols went up by 200%). It would be nice if there were a way to specify a directory or set of files to apply the keep-inlines on, and omit the rest. But that's probably too much to ask? – John Zwinck Feb 26 '14 at 05:40
  • Your build system ought to be able to help with that. With `make`, the per-directory `Makefile` could have something like `CFLAGS += -fkeep-inline-functions` – Mark Plotnick Feb 26 '14 at 09:30
  • Sorry, I meant that I want to keep inlines from #includes in directory X but omit them for the rest (e.g. /usr/include and the rest). – John Zwinck Feb 26 '14 at 13:46
2

Building your project with GCC option -gdwarf-2 may be helpful in this situation.

According to 11.1 Inline Functions in GDB documentation:

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.

Also see 3.9 Options for Debugging Your Program or GCC

Lee Duhem
  • 14,695
  • 3
  • 29
  • 47