|
Message-ID: <20141019211320.GL32028@brightrain.aerifal.cx> Date: Sun, 19 Oct 2014 17:13:20 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: debugging problem with musl ld and qemu-ppc 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_@...al-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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.