GDB Backtrace Containing Similar Addresses but Different Source Lines

Question

I was trying to debug inkscape and put a breakpoint at an address in its main shared library (ie, /usr/lib/inkscape/libinkscape_base.so ). When the execution reached that breakpoint, the backtrace was as follows:

#0  0x00007ffff6ecb220 in __static_initialization_and_destruction_0 (__priority=65535, __initialize_p=1) at /usr/include/c++/7/iostream:74
#1  0x00007ffff6ecb220 in _GLOBAL__sub_I_log_display_config.cpp(void) () at ./src/debug/log-display-config.cpp:83
#2  0x00007ffff7de5733 in call_init (env=0x7fffffffddd8, argv=0x7fffffffddc8, argc=1, l=<optimized out>) at dl-init.c:72
#3  0x00007ffff7de5733 in _dl_init (main_map=0x7ffff7ffe170, argc=1, argv=0x7fffffffddc8, env=0x7fffffffddd8) at dl-init.c:119
#4  0x00007ffff7dd60ca in _dl_start_user () at /lib64/ld-linux-x86-64.so.2
#5  0x0000000000000001 in  ()
#6  0x00007fffffffe176 in  ()
#7  0x0000000000000000 in  ()

As can be seen, #0 and #1 point to the same address but different source locations. The same is true for #2 and #3 . How is it possible?

Answer 1

How is it possible?

It's possible with inlining.

GCC emits sufficient debug info for GDB to tell that a particular address, even though it is physically located inside bar , actually belongs to inlined foo .

Since foo is "not really there", but a call to it is synthesized by GDB in the backtrace output, what address GDB prints for it is somewhat irrelevant.

GDB used to print no address at all (my version 8.3.50.20190824-24.fc31 still does), but I guess this isn't dependable, and sometimes GDB may just repeat the previous return address.