From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6417 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: Sat, 1 Nov 2014 17:47:13 -0400 Message-ID: <20141101214713.GL22465@brightrain.aerifal.cx> References: <20141016060741.GA3707@euler> <20141016153448.GY32028@brightrain.aerifal.cx> <20141016165839.GA1257@euler> <20141019202934.GA11042@euler> <20141019211320.GL32028@brightrain.aerifal.cx> <20141101214128.GA5286@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 1414878455 1246 80.91.229.3 (1 Nov 2014 21:47:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 1 Nov 2014 21:47:35 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6430-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 01 22:47:28 2014 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 1XkgW7-0003cY-C7 for gllmg-musl@m.gmane.org; Sat, 01 Nov 2014 22:47:27 +0100 Original-Received: (qmail 2015 invoked by uid 550); 1 Nov 2014 21:47:26 -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 2004 invoked from network); 1 Nov 2014 21:47:25 -0000 Content-Disposition: inline In-Reply-To: <20141101214128.GA5286@euler> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6417 Archived-At: On Sat, Nov 01, 2014 at 10:41:28PM +0100, Felix Janda wrote: > Rich Felker wrote: > > On Sun, Oct 19, 2014 at 10:29:35PM +0200, Felix Janda wrote: > [..] > > > 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. > > The construct is used in a file in gmp and this caused my home-built gcc > to crash. I'm wondering why other people have not hit this issue. (I > guess it is because they didn't use dynamic linking.) Could you give a link to the code where it's used? It would be nice to see if this is actually something broken that's assuming the insecure-plt ABI or whether it's just binutils misinterpreting it and making trouble for us. Rich