GDB CallStack地址是虚拟的还是物理的? [英] GDB CallStack Address virtual or physical?

问题描述

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

My gdb bt callstack gives function name with function address. Then I did nm binary and generated the function name and address mapping. When I tried to match gdb address with nm output it did not match. The function address in (gdb) bt where too high (looks like physical address).

gdb函数地址(例如0x00007fffe6fc150f):

gdb function address (e.g 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时，我从二进制文件中获得的地址就是这样

but when I did nm the address from the binary I got is like this

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输出地址不匹配

As i know the gdb shows only virtual address. But I dont know why it is coming so high and doesnot match with address present nm output

gdb地址是虚拟地址吗??. nm o/p从000000000开始看起来像实际的虚拟地址.但是为什么要自动添加基地址呢?

Is the gdb address are virtual address??. nm o/p looks like actual virtual address since it starts from 000000000. But then why base address are added automatically?

注意:我尝试使用示例test.out.效果很好. bt调用堆栈地址是虚拟地址，并且与nm a.out符号输出完全匹配.

Note: I tried with sample test.out. that works fine. The bt callstack address are virtual address and perfectly matches with nm a.out symbols output.

推荐答案

0x00007fffe6fc150f地址来自共享库(在本例中为libc.so.6).它是虚拟地址，但不会匹配来自c11的输出，因为库是在特定的load地址加载的，该地址不同于执行到执行.

The 0x00007fffe6fc150f address is coming from a shared library (libc.so.6 in this case). It is the virtual address, but it will not match output from nm /lib/libc.so.6 because the library is loaded at certain load address, which varies from execution to execution.

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

You can find out when libc.so.6 is loaded by executing info proc map GDB command. Once you know the load address for libc.so.6, add it to every address in nm output, and the result will match GDB output.

之所以对简单的a.out起作用，是因为(与共享库不同)a.out被链接为以固定的加载地址(在Linux x86_64上通常为0x400000)加载，并且不会被动态文件重定位.加载器.

The reason this worked for a simple a.out is that (unlike shared libraries) a.out is linked to be loaded at a fixed load address (usually 0x400000 on Linux x86_64), and is not relocated by the dynamic loader.

这篇关于GDB CallStack地址是虚拟的还是物理的?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！