[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141017211523.GA24839@euler>
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.
