Hi! As author of the HotBasic compiler for Windows, in porting same to Linux, I find that ld does not properly link relative relocations (R_386_PC32) in correct elf32-i386 .o files.
In particular, after opcode E8h (call), ld inserts a relative value which is 4 bytes too much, as if it did not take into account the position of the program counter which points to the *end* of the 4-byte value to be relocated. This happens both for procedures within the same module or in other modules in the link. I tentatively conclude that if ld works for all the elf files in a linux installation, it could only do so, if they contain such relocations, if all of those files had incorrect .text section relocation info to match (by reversing the 4 byte error) bug or fault in ld. I haven't looked yet, but ld would properly do the relative relocations if the symbol table address of a location in .o files was consistently 4 bytes less the real location of the symbol. In short, in this issue, ld is not compatible with its own stated standards for relocation. As it is now, HotBasic programs, which have correct relocation information in the .o files, cannot be linked with ld on Linux -- a major portability problem. Is there any plan to fix this or any advice re where in ld source a 4 byte correction could be added to compile a "good ld" capable of linking correct .o files. Ironically, a fixed ld would require fixing all the other software which apparently is producing incorrect .o files to match (reversing) the ld relocation error. TIA, Cordially, James Keene, PhD _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
