Re: [PATCH] PowerPC: Use correct PLT relocations for elf_machine_type_class.

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, Mar 11, 2009 at 01:44:10PM +1030, Alan Modra wrote:
> On Tue, Mar 10, 2009 at 07:31:31PM +0100, Jakub Jelinek wrote:
> > Unfortunately this change completely broke prelink on ppc64 (and as we
> > haven't rebuilt prelink in Fedora between that time and now it wasn't
> > noticed during make check, wonder why it hasn't been reported by users
> > though).  The following very ugly hack gets back at least most of the tests
> > into a working state, hopefully still compatible with the older glibc
> > LD_TRACE_PRELINKING=1 output, but the lost distinction between PLT and
> > non-PLT lookups still breaks the C++ vtable optimizations.  I'll see if
> > something can be easily done for them, but worst case the above change will
> > have to be reverted.
> 
> Sorry, I obviously didn't consider prelink when making the change.  Go
> ahead and revert it.  (Except that R_PPC64_ADDR24 was the wrong reloc
> to test for plt lookup.)
> 
> I also can't see the speedup I was claiming when I submitted the
> patch, except for the small matter of simplifying
> elf_machine_type_class.  :-(  Setting ELF_RTYPE_CLASS_PLT was aimed
> at short-circuiting multiple lookup for plt entry syms (non-zero
> SHN_UNDEF), *but ppc64 ld doesn't generate these anyway*!  

At this point I think it is preferrable to handle this in prelink, because
we have glibc 2.8 and 2.9 releases with this change in the wild.
With the prelink patch I've posted and similar change to cxx.c, it is
important to know for the pre-February 08 ppc64 glibc if it ever could print
in LD_TRACE_PRELINKING=1 different lookup values or different conflict
values for the same symbol for /0 vs. /1.  Say on x86_64 with both shared
library and binary taking address as well as calling getpid we get:
conflict 0x0000000000110000 0x0000000000000258 -> 0x0000000000400000 0x00000000004004c8 x 0x0000003eda800000 0x0000003eda8a8e20 /0 getpid
lookup 0x0000000000110000 0x0000000000000258 -> 0x0000003eda800000 0x0000003eda8a8e20 /1 getpid
lookup 0x0000000000400000 0x0000000000000300 -> 0x0000003eda800000 0x0000003eda8a8e20 /1 getpid
If ppc64 never has SHN_UNDEF symbols with non-zero st_value, I think it is
not possible; if it printed say:
lookup 0x0000000000110000 0x0000000000000258 -> 0x0000003eda800000 0x0000003eda8a8e20 /0 getpid
lookup 0x0000000000110000 0x0000000000000258 -> 0x0000003eda800000 0x0000003eda8a8e20 /1 getpid
lookup 0x0000000000400000 0x0000000000000300 -> 0x0000003eda800000 0x0000003eda8a8e20 /1 getpid
(i.e. two entries for the same library/ElfNN_Sym reference, identical except
for /0 vs. /1), then this is something the patched prelink handles just
fine.
The numbers printed by LD_TRACE_PRELINKING are object base address and relative
address into .dynsym from the base address before -> and target symbol
object base address and resolved address in the second pair (and for
conflict in the third pair as well).  The number after / is the type class
(the reason why the above change made a difference to prelink).

	Jakub