[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 1 Nov 2014 22:41:28 +0100
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 Sun, Oct 19, 2014 at 10:29:35PM +0200, Felix Janda wrote:
[..]
> > 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.
The construct is used in a file in gmp and this caused my home-built gcc
to crash. I'm wondering why other people have not hit this issue. (I
guess it is because they didn't use dynamic linking.)
Using debian code search, the construct still seems to be used in
libffi (and its copies in many projects). Looking closer, the code is
behind an #ifdef PROF and PROF isn't defined anywhere in the codebase.
That should be the reason why I had no problems with python.
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.
