Re: BUG elf32-i386 R_386_PC32 done wrong

[doctor electron]

Long, long ago, Ian Lance Taylor, a life form in far off space,
emitted:

>If you ignore the contents of the .o file, then how do you propose to
>handle the assembler code
>    call foo + 16
>?

ADDENDUM:
Thanks again for this implied explanation, where apparently rel
reloc info is split in two parts, one in the reloc table and the
other in the location to be relocated.  If this is correct, may
I add some friendly thoughts?

1. I've contemplated writing my own "LoadLibrary" and
"GetProcAddress" procedures, and your explanation (implied in
your question above) will be essential to do so correctly.

2. As one who finds much in Linux to be very praiseworthy, I
worry a bit about what seems to be such allegiance to a
20-year-old ABI doc which may be inconsistent with making
quality improvements in the future.  [No hardware maker would do
such a thing, I think, and survive; no one makes 16 bit bus
cards anymore.]  In short, the interoperability rationale may
loose its punch if the thing to be interoperable should best be
discarded.

3. Whether the "call foo + 16" case above is the right place to
break with this ABI, I don't know; but for fun and discussion,
let's consider it.

First, we might call this the "Laziness concession to compiler
writers" in that they don't have to evaluate "foo + 16" above
and just put it in the reloc table, with an autogenerated
textual symbol if necessary, as "good boys and girls" would.  If
the contents of the rel reloc location were simply ignored, the
message to compiler writers is that this splitting of reloc info
is no longer supported, in favor of the "regular" simpler,
cleaner rel reloc relocation table entry.

Second, the -4 constant is still embedded in the location
contents read by the linker -- another place where one could
break with ABI.  If linkers just used a -4 constant and the rel
reloc info in the relocation table, in effect, some advantages
of interoperability would be gained (all the .obj files would
link, whether in .obj or .o form from objcopy), and compiler
splitting of rel reloc info would be discarded.  Compiler makers
could choose to comply or not.  To comply, they would have many
options such as

lea eax,foo
add eax,16
call eax  ;no rel reloc table entry!

...or put the value of foo + 16 as the symbol address in the
reloc table as described above.

The above may not be the point to break with ABI, but my
friendly message is that major quality upgrades may be found by
dropping provisions which are not presently deemed to be
optimally efficient.  Of course, this is contrary to the "ABI is
written in stone" concept.

Again, I don't know, but it might seem almost inconceivable that
a technical specification written over 20 years ago, on almost
anything in computing software or hardware, could be completely
perfect or that the world will end if we drop support for items
such as above or even add support for new items.

If I understand, Microsoft has broken with ABI specs (e.g., they
put 0 in the location to undergo rel relocation) and lightning
did not strike them dead (actually, they have done just fine
after doing so).

SUMMARY:  I seriously wonder if continuing OS upgrades and ABI
are consistent, if ABI can prevent progress.

For my purposes, I now know the "mess" that ABI supports for rel
relocs in order to write code to do them at run-time.  Thanks
for that.

Greetings, Jim