From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6415 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: Sat, 1 Nov 2014 22:41:28 +0100 Message-ID: <20141101214128.GA5286@euler> References: <20141016060741.GA3707@euler> <20141016153448.GY32028@brightrain.aerifal.cx> <20141016165839.GA1257@euler> <20141019202934.GA11042@euler> <20141019211320.GL32028@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 1414878128 28987 80.91.229.3 (1 Nov 2014 21:42:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 1 Nov 2014 21:42:08 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6428-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 01 22:42:01 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 1XkgQp-00018h-Jb for gllmg-musl@m.gmane.org; Sat, 01 Nov 2014 22:41:59 +0100 Original-Received: (qmail 30365 invoked by uid 550); 1 Nov 2014 21:41:58 -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 30354 invoked from network); 1 Nov 2014 21:41:57 -0000 X-Virus-Scanned: amavisd-new at posteo.de Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20141019211320.GL32028@brightrain.aerifal.cx> User-Agent: Mutt/1.5.22 (2013-10-16) Xref: news.gmane.org gmane.linux.lib.musl.general:6415 Archived-At: 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.) Using debian code search, the construct still seems to be used in libffi (and its copies in many projects). Looking closer, the code is behind an #ifdef PROF and PROF isn't defined anywhere in the codebase. That should be the reason why I had no problems with python. Felix