From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: Re: building musl libc.so with gcc -flto
Date: Fri, 1 May 2015 12:10:16 +0200 [thread overview]
Message-ID: <20150501101016.GE863@port70.net> (raw)
In-Reply-To: <CAJ86T=UBk5e=oFau4GTwk2PEezMj1Re2C-AaON0XhxpgL+qOiw@mail.gmail.com>
* Andre McCurdy <armccurdy@gmail.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
next prev parent reply other threads:[~2015-05-01 10:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-22 22:48 Andre McCurdy
2015-04-23 2:23 ` Rich Felker
2015-04-23 5:34 ` Andre McCurdy
2015-04-23 9:45 ` Rich Felker
2015-04-28 0:16 ` Andre McCurdy
2015-04-28 0:24 ` Rich Felker
2015-04-28 6:23 ` Andre McCurdy
2015-04-28 13:44 ` Rich Felker
2015-04-29 1:42 ` Andre McCurdy
2015-04-29 3:27 ` Rich Felker
2015-05-01 5:48 ` Andre McCurdy
2015-05-01 10:10 ` Szabolcs Nagy [this message]
2015-05-01 15:49 ` Rich Felker
2015-04-30 20:46 ` Andy Lutomirski
2015-04-30 23:44 ` Rich Felker
2015-05-01 6:57 ` Alexander Monakov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150501101016.GE863@port70.net \
--to=nsz@port70.net \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).