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

我的gdb

bt

callstack提供函数名和函数地址。然后我做了nm二进制文件 并生成函数名和地址映射。当我尝试将gdb地址与

nm

输出匹配时，它不匹配。

（gdb）bt

中的函数地址过高（看起来像物理地址）

gdb功能地址（例如

0x00007fffe6fc150f

）：

这台机器是64位的

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

是gdb地址还是虚拟地址

nm

o/p看起来像实际的虚拟地址，因为它从000000000开始。但为什么基址会自动添加呢

---

注意：我尝试了sample test.out。那很好。

bt

调用堆栈地址是虚拟地址，与

nm a.out

符号输出完全匹配。

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

），并且不被动态加载程序重新定位

#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 

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