From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7564 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: building musl libc.so with gcc -flto Date: Fri, 1 May 2015 11:49:04 -0400 Message-ID: <20150501154904.GZ17573@brightrain.aerifal.cx> References: <20150423094520.GA17573@brightrain.aerifal.cx> <20150428002402.GJ17573@brightrain.aerifal.cx> <20150428134453.GM17573@brightrain.aerifal.cx> <20150429032725.GT17573@brightrain.aerifal.cx> <20150501101016.GE863@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1430495366 24515 80.91.229.3 (1 May 2015 15:49:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 May 2015 15:49:26 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7577-gllmg-musl=m.gmane.org@lists.openwall.com Fri May 01 17:49:20 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YoDBn-0002lb-Ez for gllmg-musl@m.gmane.org; Fri, 01 May 2015 17:49:19 +0200 Original-Received: (qmail 27973 invoked by uid 550); 1 May 2015 15:49:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 27955 invoked from network); 1 May 2015 15:49:17 -0000 Content-Disposition: inline In-Reply-To: <20150501101016.GE863@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7564 Archived-At: On Fri, May 01, 2015 at 12:10:16PM +0200, Szabolcs Nagy wrote: > * Andre McCurdy [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 : > 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 > 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 > .... The problem is that gold does not know how to process relocations for undefined weak references correctly. When the code in question is PIC/PIE, the weak reference can be kept for resolving at runtime. Instead of: 804846f: b8 70 83 04 08 mov $0x8048370,%eax where the linker filled in a fixed address (the PLT slot) which the code happily sees is non-zero and then calls it, PIC code would read the address from the GOT. In non-PIC code, the linker (ld) *MUST* resolve undefined weak references to the address zero; they are not overridable at runtime because non-PIC doesn't support that. This is a bug in gold, but I have no idea how it works at all, even with glibc. The same issue should arise in gcc's crt files. You can probably work around it for now by building the app as PIE. Rich