Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 Oct 2014 23:15:23 +0200
From: Felix Janda <felix.janda@...teo.de>
To: musl@...ts.openwall.com
Subject: Re: debugging problem with musl ld and qemu-ppc

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 <<EOF
> > 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

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.