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? > [EMAIL PROTECTED]:~/cockpit/build/linuxgcc/scripting$ readelf -r PerlWrapper.o > | grep getenv > 00000128 07612 R_PPC_PLTREL24 00000000 getenv This is ok. > [EMAIL PROTECTED]:~/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...
