If I try to compile that small program staticaly : $ cat conftest.c int main () { ; return 0; } $ x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -fomit-frame-pointer -mtune=core2 -D_GNU_SOURCE -g -ggdb -static conftest.c It segfault : $ ./a.out Segmentation fault A backtrace : $ gdb ./a.out ... (gdb) r Starting program: /var/tmp/a.out Program received signal SIGSEGV, Segmentation fault. 0xffffffffffffffff in ?? () (gdb) bt #0 0xffffffffffffffff in ?? () #1 0x0000000000400c8c in __libc_csu_init () #2 0x0000000000400699 in __libc_start_main () #3 0x0000000000400409 in _start () If I compile it as shared, all is fine : $ x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -fomit-frame-pointer -mtune=core2 -D_GNU_SOURCE -g -ggdb conftest.c $ ./a.out Attached a emerge --info Is a objdump -d necessary ? Reproducible: Always
Created attachment 293761 [details] emerge --info
*** Bug 391939 has been marked as a duplicate of this bug. ***
Looks like binutils-2.22 make the linking fail some way so the static bin don't work.
Looks like binutils 2.22 don't like the pie/static hybrid crtbeginTS.o Something get wrong. On older binutils it was working fine. Mike do you have any hint where to look in the binutils code for it?
Created attachment 294519 [details, diff] binutils-2.22-initfini-pie.patch
(In reply to comment #5) > Created attachment 294519 [details, diff] [details, diff] > binutils-2.22-initfini-pie.patch Tested and it works, thank you Mike can we include it in next patch bump?
if we look at ld/scripttempl/elf.sc, i'm a bit uneasy by our crt handling. aren't we already missing handling later on in the file ? ... CTOR=".ctors ${CONSTRUCTING-0} : ... KEEP (*crtbegin.o(.ctors)) KEEP (*crtbegin?.o(.ctors)) ... KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o $OTHER_EXCLUDE_FILES) .ctors)) KEEP (*(SORT(.ctors.*))) KEEP (*(.ctors)) ... DTOR=".dtors ${CONSTRUCTING-0} : ... KEEP (*crtbegin.o(.dtors)) KEEP (*crtbegin?.o(.dtors)) KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o $OTHER_EXCLUDE_FILES) .dtors)) KEEP (*(SORT(.dtors.*))) ...
more related URLs: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 http://sourceware.org/ml/binutils/2010-12/msg00439.html
Like this...? @@ -264,6 +264,7 @@ CTOR=".ctors ${CONSTRUCTING-0} : KEEP (*crtbegin.o(.ctors)) KEEP (*crtbegin?.o(.ctors)) + KEEP (*crtbeginTS.o(.ctors)) /* We don't want to include the .ctor section from the crtend.o file until after the sorted ctors. @@ -280,6 +281,7 @@ DTOR=".dtors ${CONSTRUCTING-0} : ${CONSTRUCTING+${DTOR_START}} KEEP (*crtbegin.o(.dtors)) KEEP (*crtbegin?.o(.dtors)) + KEEP (*crtbeginTS.o(.dtors)) KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o $OTHER_EXCLUDE_FILES) .dtors)) KEEP (*(SORT(.dtors.*))) KEEP (*(.dtors))
that would be my guess ... but i'd like it if some hardened peeps did some testing before we commit that :)
(In reply to comment #10) > that would be my guess ... but i'd like it if some hardened peeps did some > testing before we commit that :) I tested applying the patch in comments 5 and 9 and it resolves the issue.
Works fine here to.
someone should post a patch i can actually d/l and apply ;)
Created attachment 294895 [details, diff] Add support for crtbeginTS.o Add support for the crtbeginTS.o from hardened gcc.
Comment on attachment 294895 [details, diff] Add support for crtbeginTS.o i think you've got a copy & paste typo here; i'll fix it up when i commit: KEEP (*crtbegin?.o(.dtors)) + KEEP (*crtbeginTS.o(.ctors)) pretty sure that should be .dtors
queued in the 2.22 patchset. i'll bump once i go through open bugs to make sure there are no other pending things to include.
*** Bug 393327 has been marked as a duplicate of this bug. ***
FYI i'm dropping this patch starting with 2.26.1 since it's been in gcc long enough. i'll prob drop it from older binutils too, just not do an explicit patchset push for it.