GDB CallStack Address virtual or physical? - gdb

Question

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 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
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
The Machine is 64 bit.
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
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?
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.

Answer 1

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.
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.
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.