[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150501101016.GE863@port70.net>
Date: Fri, 1 May 2015 12:10:16 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: building musl libc.so with gcc -flto
* Andre McCurdy <armccurdy@...il.com> [2015-04-30 22:48:09 -0700]:
> I'm able to reproduce the problem I saw previously with the latest
> musl git version. Behaviour is that some binaries dynamically linked
> with gold (notably busybox) seem to run well but most binaries
> segfault at startup.
>
> I'm using gcc 4.9.2 and binutils 2.25, but I should also mention that
> I'm using OpenEmbedded to build the toolchain and musl support in OE
> is still quite experimental...
>
> Below is a link to a base64 encoded tar file containing two
> dynamically linked "hello world" x86 binaries. Both were created using
> the same OE toolchain (the only difference was the -fuse-ld=XXX option
> used). "hello.bfd" runs well, "hello.gold" segfaults. Hopefully they
> can give some clues about what's happening.
>
> http://pastebin.com/raw.php?i=RKJBqAg1
$ nm -D hello.gold
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
w _Jv_RegisterClasses
08049670 A __bss_start
w __deregister_frame_info
U __libc_start_main
w __register_frame_info
08049670 A _edata
08049690 A _end
U printf
$ nm -D hello.bfd
08049564 B __bss_start
U __libc_start_main
08049564 D _edata
08049584 B _end
U printf
i'm not sure where gold expects __register_frame_info to be defined..
the call chain is
__dls3 -> do_init_fini -> _init -> frame_dummy -> __register_frame_info@plt -> 0
objdump:
0804846e <frame_dummy>:
804846e: 55 push %ebp
804846f: b8 70 83 04 08 mov $0x8048370,%eax
8048474: 89 e5 mov %esp,%ebp
8048476: 83 ec 08 sub $0x8,%esp
8048479: 85 c0 test %eax,%eax
804847b: 74 14 je 8048491 <frame_dummy+0x23>
804847d: 50 push %eax
804847e: 50 push %eax
804847f: 68 78 96 04 08 push $0x8049678
8048484: 68 18 85 04 08 push $0x8048518
8048489: e8 e2 fe ff ff call 8048370 <__register_frame_info@plt>
...
08048370 <__register_frame_info@plt>:
8048370: ff 25 50 96 04 08 jmp *0x8049650
...
GOT at this point:
0x08049648: 0xf7f92263 (__libc_start_main)
0x0804964c: 0x00000000 (should be __deregister_frame_info?)
0x08049650: 0x00000000 (should be __register_frame_info?)
0x08049654: 0xf7fbedeb (printf)
readelf says:
Relocation section '.rel.plt' at offset 0x308 contains 4 entries:
Offset Info Type Sym.Value Sym. Name
08049648 00000107 R_386_JUMP_SLOT 00000000 __libc_start_main
0804964c 00000907 R_386_JUMP_SLOT 08048360 __deregister_frame_inf
08049650 00000607 R_386_JUMP_SLOT 08048370 __register_frame_info
08049654 00000507 R_386_JUMP_SLOT 00000000 printf
Symbol table '.dynsym' contains 11 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main
2: 00000000 0 NOTYPE WEAK DEFAULT UND _ITM_deregisterTMCloneTab
3: 00000000 0 NOTYPE WEAK DEFAULT UND _ITM_registerTMCloneTable
4: 00000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses
5: 00000000 0 FUNC GLOBAL DEFAULT UND printf
6: 08048370 0 FUNC WEAK DEFAULT UND __register_frame_info
7: 08049690 0 NOTYPE GLOBAL DEFAULT ABS _end
8: 08049670 0 NOTYPE GLOBAL DEFAULT ABS _edata
9: 08048360 0 FUNC WEAK DEFAULT UND __deregister_frame_info
10: 08049670 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
Symbol table '.symtab' contains 39 entries:
Num: Value Size Type Bind Vis Ndx Name
...
32: 00000000 0 FUNC WEAK DEFAULT UND __deregister_frame_info
33: 00000000 0 FUNC WEAK DEFAULT UND __register_frame_info
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
