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

Popular posts from this blog

php - Vagrant up error - Uncaught Reflection Exception: Class DOMDocument does not exist -

vue.js - Create hooks for automated testing -

Add new key value to json node in java -