This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: elf64-ppc.c *r_offset patch
- From: Jakub Jelinek <jakub at redhat dot com>
- To: binutils at sources dot redhat dot com
- Date: Mon, 16 Jun 2003 10:04:48 +0200
- Subject: Re: elf64-ppc.c *r_offset patch
- References: <20030614093430.GD24872@sunsite.ms.mff.cuni.cz> <20030614095552.GU23826@bubble.sa.bigpond.net.au> <20030614102652.GE24872@sunsite.ms.mff.cuni.cz> <20030614125547.GV23826@bubble.sa.bigpond.net.au> <20030614151535.N15481@devserv.devel.redhat.com> <20030614235412.GW23826@bubble.sa.bigpond.net.au> <20030615001712.GX23826@bubble.sa.bigpond.net.au> <20030615085622.P15481@devserv.devel.redhat.com> <20030616040839.GB23826@bubble.sa.bigpond.net.au>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Mon, Jun 16, 2003 at 01:38:39PM +0930, Alan Modra wrote:
> Jakub found an error in handling of DTPMOD dynamic relocs, and we've
> been throwing patches at each other over the weekend with the aim of
> making prelink work on powerpc64. It's perhaps a little early to apply
> this one, as we haven't quite finished arguing. :) Maybe I'm missing
> some prelink requirement, but I guess the rest of the discussion can
> occur on the mailing list. The prelink aspect of the patch arranges for
> section contents at r_offset to be written equal to r_addend for
> R_PPC64_RELATIVE relocs, and to zero for other reloc types. We need
> RELATIVE relocs to be applied like this in the .opd section to suit the
> way our ld.so works, the choice for other relocs is somewhat arbitrary.
For the sake of prelinking existing ppc64 binaries and libraries, I'd
appreciate if R_PPC64_ADDR64 could be *r_offset == r_addend as well,
the rest can be set to 0 if you prefer.
A little background why prelink needs this:
prelink supports --undo and --verify switches. The former is supposed to
be bitwise exact copy of the binary or library before prelinking, the latter
effectively does an --undo operation followed by normal prelink operation
and checks whether the result is identical with the library/binary before
--undo and gives the unprelinked file image to the verificating utility.
As prelink does not want to bloat the binary/library unnecessarily and has
to overwrite *r_offset with the final resolved addresses in prelinked
program, it needs a way to compute the content of *r_offset during --undo
from the things which are the same in prelinked and non-prelinked image,
like relocation type, section r_offset is in, r_addend, etc.
Now, when I checked around a thousand of ppc64 binaries/libraries, I found
with the exception of glibc only R_PPC64_JMP_SLOT, R_PPC64_ADDR64, R_PPC64_COPY
and R_PPC64_RELATIVE relocations in use. R_PPC64_JMP_SLOT is uninteresting here,
as in unprelinked binaries/libraries .plt section is SHT_NOBITS, which
means *r_offset is 0. R_PPC64_RELATIVE and R_PPC64_ADDR64 relocs followed
in all binaries/libraries I checked *r_offset == r_addend (again, with
exception of glibc, where some R_PPC64_RELATIVE relocs against .got section
had *r_offset == 0 && r_addend != 0).
So, if R_PPC64_ADDR64 would be now *r_offset == 0, newly linked
binaries/libraries can be prelinked and prelink --undo'ed just fine, while
all current binaries/libraries can be prelinked but --undo will give
different bits (e.g. package management programs might complain, etc.).
> @@ -8315,9 +8329,14 @@ ppc64_elf_relocate_section (output_bfd,
>
> /* If this reloc is against an external symbol, it will
> be computed at runtime, so there's no need to do
> - anything now. */
> + anything now. However, for the sake of prelink ensure
> + that the section contents are a known value. */
> if (! relocate)
> - continue;
> + {
> + relocation = 0;
> + addend = 0;
> + unresolved_reloc = FALSE;
> + }
Will this handle pc relative relocs correctly?
Stuff like:
echo '.data; .8byte foo + 128 - .' > test.s
gcc -shared -o test.so test.s -nostdlib
Jakub