From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6351 Path: news.gmane.org!not-for-mail From: Felix Janda Newsgroups: gmane.linux.lib.musl.general Subject: Re: debugging problem with musl ld and qemu-ppc Date: Thu, 16 Oct 2014 18:58:40 +0200 Message-ID: <20141016165839.GA1257@euler> References: <20141016060741.GA3707@euler> <20141016153448.GY32028@brightrain.aerifal.cx> 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 1413478751 6440 80.91.229.3 (16 Oct 2014 16:59:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Oct 2014 16:59:11 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6364-gllmg-musl=m.gmane.org@lists.openwall.com Thu Oct 16 18:59:03 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XeoOF-0004gM-3S for gllmg-musl@plane.gmane.org; Thu, 16 Oct 2014 18:59:03 +0200 Original-Received: (qmail 13816 invoked by uid 550); 16 Oct 2014 16:59:02 -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 13808 invoked from network); 16 Oct 2014 16:59:01 -0000 X-Virus-Scanned: amavisd-new at posteo.de Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20141016153448.GY32028@brightrain.aerifal.cx> User-Agent: Mutt/1.5.22 (2013-10-16) Xref: news.gmane.org gmane.linux.lib.musl.general:6351 Archived-At: Rich Felker wrote: > On Thu, Oct 16, 2014 at 08:09:01AM +0200, Felix Janda wrote: > > Hello list, > > > > can you maybe help me debugging the following problem with qemu-ppc? > > It gives an invalid instruction error after doing: > > > > tar -xf crossx86-powerpc-linux-musl-0.9.9.tar.xz > > # (I get something similar for other versions of musl or gcc) > > cat > a.s < > b _GLOBAL_OFFSET_TABLE_@local > > EOF > > cat > b.c < > int main(void) { return 0; } > > EOF > > ../powerpc-linux-musl/bin/powerpc-linux-musl-gcc -o good b.c > > ../powerpc-linux-musl/bin/powerpc-linux-musl-gcc -o bad a.s b.c > > # set up symlinks to make 'qemu-ppc good' work > > qemu-ppc bad > > > > After musl ld has done its work it jumps to libgcc's _init and > > very soon tries to execute some data. > > > > When executing in some chroot the 'qemu-ppc -d in_asm' for > > good and bad is exactly the same up to two instructions in > > libgcc until it diverges (and bad crashes). > > > > Do you have any ideas what could be the problem? > > Using the cross compiler I had lying around, I get a warning while > linking "bad": > > /opt/powerpc-linux-musl/bin/../lib/gcc/powerpc-linux-musl/4.7.2/../../../../powerpc-linux-musl/bin/ld: bss-plt forced due to /tmp/ccfPiE1t.o > > I suspect this is happening for you too (possibly without a warning > being printed?) and that this is the cause of the problem: something > about your asm file is forcing the linker to use the old "bss-plt" > dynamic linking model, which musl does not support, rather than the > "secure-plt" model. Thanks for reproducing the issue and explaining what is bss-plt. Depending on the compiler I also got this warning. Sorry for forgetting to mention this. > The "bss-plt" model requires the dynamic linker to generate direct > call instructions inline in a writable (mode rwx!) page rather than > having the PLT thunks load their actual function addresses from > pointers filled into the GOT by the dynamic linker, so it's a major > risk from a security standpoint, and also a lot more work to implement > in the dynamic linker. As such, when powerpc support was added we > opted to omit this model and push for use of the more secure model > that works like every other arch. > > What I'm not clear about is the cause for why the linker is forcing > you back to the bss-plt model. It might be a matter of the strange > relocation type you put in a.s: > > 00000000 <.text>: > 0: 48 00 00 00 b 0x0 > 0: R_PPC_LOCAL24PC _GLOBAL_OFFSET_TABLE_ The problem caused a self-compiled native gcc to crash because the file "mpn/powerpc32/elf.m4" (used to generate some assembly) in the gmp tree contains a similar instruction. I've found the part in binutils emitting the warning and will try to see why it forces bss-plt. Thanks, Felix