From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6374 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: debugging problem with musl ld and qemu-ppc Date: Sun, 19 Oct 2014 17:13:20 -0400 Message-ID: <20141019211320.GL32028@brightrain.aerifal.cx> References: <20141016060741.GA3707@euler> <20141016153448.GY32028@brightrain.aerifal.cx> <20141016165839.GA1257@euler> <20141019202934.GA11042@euler> 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 1413753232 11264 80.91.229.3 (19 Oct 2014 21:13:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Oct 2014 21:13:52 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6387-gllmg-musl=m.gmane.org@lists.openwall.com Sun Oct 19 23:13:45 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 1XfxnN-0002SR-Gb for gllmg-musl@plane.gmane.org; Sun, 19 Oct 2014 23:13:45 +0200 Original-Received: (qmail 1805 invoked by uid 550); 19 Oct 2014 21:13:40 -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 1745 invoked from network); 19 Oct 2014 21:13:33 -0000 Content-Disposition: inline In-Reply-To: <20141019202934.GA11042@euler> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6374 Archived-At: On Sun, Oct 19, 2014 at 10:29:35PM +0200, Felix Janda wrote: > Felix Janda wrote: > > Rich Felker wrote: > [..] > > > 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. > > This seems to be caused by the part starting from lines 4267 in [1] > > /* This refers only to functions defined in the shared library. */ > case R_PPC_LOCAL24PC: > if (h != NULL && h == htab->elf.hgot && htab->plt_type == PLT_UNSET) > { > htab->plt_type = PLT_OLD; > htab->old_bfd = abfd; > } > > I think it was added to be helpful and detect the construction > > bl _GLOBAL_OFFSET_TABLE_@local-4 > mflr r30 > > intended to load a pointer to the got into r30, which no longer works > with secure-plt. See [2]. Nice job tracking this down. If there's not a reason you need this specific construct, I would just avoid it, but really the above hack should be removed from binutils. There are all sorts of asm constructs that are specific to one ABI, and the presence of something that seems to be specific to one ABI is not a justification for ignoring the user's choice of link options. Rich