[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150518201043.GX17573@brightrain.aerifal.cx>
Date: Mon, 18 May 2015 16:10:43 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: ppc soft-float regression
On Mon, May 18, 2015 at 08:39:30PM +0200, Felix Janda wrote:
> Something seems to be wrong with the powerpc copy relocations.
>
> Attached is a binary for testing (qemu-ppc works fine). It is compiled
> from
>
>
> #include <stdio.h>
>
> extern char **environ;
>
> int main(int argc, char **argv)
> {
> printf("%p %p\n", environ, &argv[argc + 1]);
> return 0;
> }
>
>
> Output before dynamic linker overhaul:
>
> 0xf6f4f830 0xf6f4f830
>
> and after:
>
> 0 0xf6f4f830
>
>
> It seems to me that the dynamic linker indeed copies environ, which is
> 0 at that point, but that __init_libc uses the old location of environ.
OK I've looked at this and I understand what's happening. PowerPC does
not have a separate relocation type for GOT entries; instead it uses
the same relocation type used for address constants global data. These
do not get re-processed after the main program and libraries are
added, because unlike GOT slots, they have addends, and if the addend
is inline (using REL rather than RELA) then it's already been
clobbered by the early relocation phase and can't easily be recovered.
I see three possible solutions:
1. Treat R_PPC_ADDR32 as a GOT relocation instead of a regular
symbolic relocation in data. This would suppress the addend (giving
wrong address) if inline addends (REL) were used, but in practice
powerpc aways uses RELA. I consider this a hack, and perhaps risky,
since in principle someone could make powerpc binaries with REL.
2. Re-process not just GOT type relocs, but also any RELA
(non-inline-addend) relocs again on the second pass. This would
work as long as powerpc only uses RELA, and if REL is ever used,
the worst that would happen is the current bug (losing environ,
etc.) rather than silently wrong relocations in global data. This
approach is not a hack, but I consider it something of an
incomplete fix.
3. Re-process all symbolic relocations. For REL-type (inline addend),
we have to recover the original addend, which can be done by
calling find_sym again, but using ldso instead of the current
library chain head as the context to search for the symbol in, then
subtracting the resulting address to get back the original addend.
I like the third solution best, even though it incurs a small code
size cost and a performance cost for archs using REL, because it's
completely robust against any weird ways some archs might end up using
relocations. The expected number of such relocations is tiny anyway;
on my i386 builds it's 14.
If option 3 proves to be difficult or costly, however, we could
consider option 2 as a temporary measure to get powerpc working. It
wouldn't even need to be reverted, because option 3 includes/subsumes
the work that would be done for option 2.
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.
