Re: R_PPC_REL24 relocation out of range
On Thu, Jul 26, 2001 at 05:58:28PM -0600, Bradley C. Midgley wrote:
> Dan,
>
> thanks for weighing in. people at work are suggesting that this kind of
> problem shows that ppc isn't stable enough for real work but i want to
> show them it's not *representative* -- it's *anomalous* :)
Actually, it shows me that your build scripts are not clean
enough to handle a decent architecture. =)
> is there another way i can tell the compiler that 24-bit relocations are
> likely to be out of range? i thought -fPIC did that but if it doesn't fit
> this purpose, please let me know.
> i have to admit i don't know the difference. i only noticed that .o files
> didn't have any R_PPC_REL24 relocations but the .so generated from them
> doesn't have any R_PPC_PLTREL24 so i figured they were the same thing in
> different forms:
The differences are subtle. In .so executables, all the symbol
resolution is done at run time -- this is how it is possible to
redefine malloc() in an application, and libc will use _that_
instead of it's internal malloc(). The mechanism to do this is
the R_PPC_PLTREL24 reloc (which occurs in .o files, but gets
converted to a R_PPC_JMP_SLOT in executables). This indicates
to the final linker that the branch should always go through the
PLT (procedure link table), in case the user wants to redefine the
symbol. Note that it may go through the PLT for other reasons,
i.e., if the symbol is resolved in a different shared object.
However, unlike normal executables, when the linker makes a .so
executable, it doesn't resolve external references (i.e., like
getenv below) that are R_PPC_REL24 relocs into jumps to the
PLT table, and thereby converting them to R_PPC_JMP_SLOT, which
is a trampoline that will jump anywhere in the address space.
It's most likely this way because the ABI tells the linker to
be overly pedantic. But then, I've seen a lot of pedantry in
the PowerPC toolchain -- many things are more strict than That
Other Architecture, and for good reason.
I don't suppose you could provide source code and build scripts?
> bmidgley@clam:~/cockpit/build/linuxgcc/scripting$ readelf -r PerlWrapper.o
> | grep getenv
> 00000128 07612 R_PPC_PLTREL24 00000000 getenv
This is ok.
> bmidgley@clam:~/cockpit/build/linuxgcc/scripting$ readelf -r
> ../modules/libscripting-1-0.so | grep getenv
> 000177b0 0850a R_PPC_REL24 00000000 getenv
This is a problem. I doubt this reloc comes from PerlWrapper.o.
dave...
Reply to: