Re: debugging problem with musl ld and qemu-ppc

[Rich Felker <dalias@libc.org>]

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