GDB调用堆栈地址是虚拟的还是物理的？答案

【问题标题】：GDB CallStack Address virtual or physical?GDB调用堆栈地址是虚拟的还是物理的？
【发布时间】：2012-05-16 03:53:57
【问题描述】：

我的 gdb bt callstack 给出了函数名和函数地址。然后我做了nm binary 并生成函数名称和地址映射。当我尝试将 gdb 地址与nm 输出匹配时，它不匹配。 (gdb) bt 中的函数地址太高（看起来像物理地址）。

gdb函数地址（如0x00007fffe6fc150f）：

#9  0x00007fffe6fc150f in read_alias_file (fname=<value optimized out>, fname_len=<value optimized out>) at localealias.c:224
#10 0x00007fffe6fc1a4e in _nl_expand_alias (name=0x7fffffffed04 "en_IN") at localealias.c:189
#11 0x00007fffe6fbb62f in _nl_find_locale (locale_path=0x7fffe70df580 "/usr/lib/locale", locale_path_len=16, category=12, name=0x7fffffffdb90) at findlocale.c:119
#12 0x00007fffe6fbacf6 in *__GI_setlocale (catesagory=12, locale=<value optimized out>) at setlocale.c:303
#13 0x00007ffff17b8686 in

但是当我做nm时，我得到的二进制地址是这样的

0000000005ddda04 t StubGLBindFragDataLocationIndexed
0000000005ddda3f t StubGLBindFramebuffer
0000000005ddda65 t StubGLBindRenderbuffer
0000000005ddda8b t StubGLBindTexture
0000000005dddab1 t StubGLBlendColor
0000000005dddaef t StubGLBlendFunc
0000000005dddb15 t StubGLBlitFramebuffer
0000000005dddb7e t StubGLBufferData
0000000005dddbbd t StubGLBufferSubData
0000000005dddc00 t StubGLCheckFramebufferStatus
0000000005dddc1e t StubGLClear
0000000005dddc3c t StubGLClearColor
0000000005dddc7a t StubGLClearStencil
0000000005dddc98 t StubGLColorMask
0000000005dddcda t StubGLCompileShader

机器是 64 位的。

据我所知，gdb 只显示虚拟地址。但我不知道为什么它会这么高而且与当前 nm 输出的地址不匹配

难道gdb地址都是虚拟地址？？？。 nm o/p 从 000000000 开始看起来像实际的虚拟地址。但是为什么会自动添加基地址呢？

注意：我尝试使用示例 test.out。效果很好。 bt 调用栈地址为虚拟地址，与nm a.out 符号输出完美匹配。

【问题讨论】：

标签： gdb virtual symbols nm

【解决方案1】：

0x00007fffe6fc150f 地址来自共享库（在本例中为libc.so.6）。它是虚拟地址，但它将不匹配来自nm /lib/libc.so.6的输出，因为库是在某个加载地址加载的，该地址从执行到执行。

您可以通过执行info proc map GDB 命令了解何时加载libc.so.6。一旦知道libc.so.6 的加载地址，将其添加到nm 输出中的每个地址，结果将与GDB 输出匹配。

这对简单的a.out 起作用的原因是（与共享库不同）a.out 链接到固定加载地址（通常在 Linux x86_64 上为0x400000），并且不会被动态重定位装载机。

【讨论】：