1

我试图调试并在其主共享库（即， ）inkscape中的地址处放置一个断点。/usr/lib/inkscape/libinkscape_base.so当执行到达该断点时，回溯如下：

#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  ()

可以看出，#0和#1指向相同的地址但不同的源位置。#2和也是如此#3。这怎么可能？

4

1 回答 1

2

这怎么可能？

内联是可能的。

GCC 为 GDB 发出足够的调试信息来告诉特定地址，即使它物理上位于内部bar，实际上属于 inlined foo。

由于foo“不是真的存在”，但是GDB 在输出中合成backtrace了对它的调用，因此GDB 为它打印的地址有些无关紧要。

GDB 过去根本不打印地址（我的版本8.3.50.20190824-24.fc31仍然如此），但我想这不可靠，有时 GDB 可能只是重复以前的返回地址。

于 2019-11-27T14:56:51.973 回答