Re: BUG elf32-i386 R_386_PC32 done wrong

[Ian Lance Taylor]

doctor electron <address@hidden> writes:

> >> 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.
> >
> >GNU ld is correct according to the ELF ABI Processor Supplement for
> >i386 Processors.
> 
> Thank you for your reply, Ian.  The first smoking gun was
> described in my first email:  ld overshoots the target for rel
> relocs within module by 4 bytes.  This is undeniably a linker
> failure.  The processor adds the value in the rel relocated
> address to eip ... and, period; that's it.  ld does not know how
> i386 and essentially all other microprocessors work.  There is
> no other credible explanation.

Please allow me to repeat: GNU ld is correct according to the ELF ABI
Processor Supplement for i386 Processors.  If you want to convince
anybody, you need to start by reading that document and explaining
where GNU ld fails to follow it precisely.

> The one and only formula for rel relocs is:
> 
> S - (A + 4)

That turns out not to be the case.  Read the ABI.

> Notice that the contents of that E8 field in the
> .obj or .o is irrelevant, it should be overwritten.

That turns out not to be the case.  Read the ABI.

> [This is why it looks ridiculous (!) to see -4 in these
> locations in existing linux .o and .so files -- really looks
> like people have no idea what they are doing -- KeyStone Cops.
> I would like to be an advocate/promoter of Linux, but this, my
> friend, is totally second-class.]  

I note that when we wrote this code Eric Youngdale and I tested it
against the ELF linker independently developed for i386 UnixWare (an
SVR4 port).  The GNU linker correctly handled UnixWare .o files, and
vice-versa.  So this is hardly a Linux-specific issue.

> So I humbly ask again:  Where is this code, so e might best find
> this code in ld, rewrite it correctly, and then ld would link
> all i386 formats, for both good and existing (contain the -4
> gibberish) input files.

Look for R_386_PC32 in bfd/elf32-i386.c.

But consider the alternatives:

1) Every single existing i386 ELF object file is wrong, every existing
   i386 ELF linker is wrong, every existing i386 ELF assembler is
   wrong, the i386 ELF ABI is wrong.

or

2) You are wrong.

Between those two, I know which one I would pick.

Ian