c - Symbol offsets reported by objdump no longer match run-time offsets -
in previous versions of gcc, symbol offsets reported objdump
matched ones used during actual execution of code. example:
$ cat example.c #include <stdio.h> int g_someglobal = 0; int main() { printf("%d\n", g_someglobal); return 0; } $ gcc-6 -v ... gcc version 6.1.1 20160802 (debian 6.1.1-11) $ gcc-6 -o0 -g -o example example.c $ objdump -x example | grep global ... 080496f4 g o .bss 00000004 g_someglobal ...
and indeed, when running binary, actual address of symbol used during execution same 1 reported objdump:
$ gdb ./example ... (gdb) start temporary breakpoint 1, main () @ example.c:10 10 printf("%d\n", g_someglobal); (gdb) p/x &g_someglobal $1 = 0x80496f4
unfortunately, repeating same sequence of commands in released debian stretch, happens instead:
$ gcc-6 -v ... gcc version 6.3.0 20170415 (debian 6.3.0-14) $ gcc-6 -o0 -g -o example example.c $ objdump -x example | grep global 00002020 g o .bss 00000004 g_someglobal
the symbol offset seems smaller value - which...
$ gdb ./example ... (gdb) start ... temporary breakpoint 1, main () @ example.c:7 7 printf("%d\n", g_someglobal); (gdb) p/x &g_someglobal $1 = 0x80002020
...no longer matches 1 used @ runtime.
am making mistake here? has usage of tools changed in meantime? if not, reasoning behind change?
regardless - in theory there must way "expected run-time offset" of .bss segment hosts variable (objdump
report section placed in, final run-time position calculated adding .bss
offset). in preliminary attempts so, have not found way this, though:
$ readelf --sections example | grep bss [26] .bss nobits 0000201c 00101c 000008 00 wa 0 0 4
this doesn't seem report "shift" of 0x80000000 seems happen .bss
-hosted variables in example.
(even if "magic constant" new execution environment, apply .data
variables, too? , honest, hate magic values - previously, whatever came out of objdump -x
accurate, regardless of symbols resided...)
any information resolve welcome. ideally, i'd reproduce old behavior of objdump -x
- i.e. statically (not @ run-time) value of run-time address of symbol, elf hosts it.
update: did custom compile (from sources) of gcc7.1.0, , no longer reproducible. perhaps regression in gcc 6.3 (the version packaged in debian stretch)...
the reason debian's gcc package built --enable-default-pie
. in pie executable, elf segments can loaded @ arbitrary (as long it's aligned) base address, chosen randomly loader. symbol addresses see in elf file offsets relative base address it's loaded at, rather absolute virtual addresses.
if don't want/need pie, can add -no-pie
link command line link-time determined addresses you're used to.
Comments
Post a Comment