From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6360 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: Fri, 17 Oct 2014 23:15:23 +0200 Message-ID: <20141017211523.GA24839@euler> References: <20141016060741.GA3707@euler> <20141016153448.GY32028@brightrain.aerifal.cx> <20141017193039.GA18959@euler> <20141017201755.GD32028@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 1413580551 27475 80.91.229.3 (17 Oct 2014 21:15:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Oct 2014 21:15:51 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6373-gllmg-musl=m.gmane.org@lists.openwall.com Fri Oct 17 23:15:44 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 1XfEsC-0000aH-72 for gllmg-musl@plane.gmane.org; Fri, 17 Oct 2014 23:15:44 +0200 Original-Received: (qmail 3177 invoked by uid 550); 17 Oct 2014 21:15:43 -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 3169 invoked from network); 17 Oct 2014 21:15:43 -0000 X-Virus-Scanned: amavisd-new at posteo.de Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20141017201755.GD32028@brightrain.aerifal.cx> User-Agent: Mutt/1.5.22 (2013-10-16) Xref: news.gmane.org gmane.linux.lib.musl.general:6360 Archived-At: Rich Felker wrote: > On Fri, Oct 17, 2014 at 09:30:39PM +0200, 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_ > > > > It also seems to be possible to get this kind of relocation by doing > > > > cat > a.c < > extern int __attribute__ ((__visibility__ ("hidden"))) f(void); > > int main(void) { return f(); } > > EOF > > gcc -c a.c > > This should not happen if gcc is built to use secure-plt mode. gcc > should use whatever relocation types work for it. If it does, it's a > bug in some part of the toolchain. Really I don't get why ld rejects > the relocation. It seems perfectly valid to me. Here indeed everything is ok. While a.o will have a R_PPC_LOCAL24PC relocation it is resolved without falling back to bss-plt. Felix