GDB调用堆栈地址虚拟还是物理?
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了GDB调用堆栈地址虚拟还是物理?相关的知识,希望对你有一定的参考价值。
我的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。工作正常。 qazxsw poi调用堆栈地址是虚拟地址,与qazxsw poi符号输出完美匹配。
bt
地址来自共享库(在本例中为nm a.out
)。它是虚拟地址,但它不匹配来自0x00007fffe6fc150f
的输出,因为库是在某个加载地址加载的,该加载地址因执行而异。
你可以通过执行libc.so.6
GDB命令找出加载nm /lib/libc.so.6
的时间。一旦知道libc.so.6
的加载地址,将其添加到info proc map
输出中的每个地址,结果将匹配GDB输出。
这对于一个简单的libc.so.6
起作用的原因是(与共享库不同)nm
被链接到一个固定的加载地址(通常是Linux x86_64上的a.out
),并且没有被动态加载器重新定位。
以上是关于GDB调用堆栈地址虚拟还是物理?的主要内容,如果未能解决你的问题,请参考以下文章