BUG elf32-i386 R_386_PC32 done wrong

[doctor electron]

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