Re: BUG elf32-i386 R_386_PC32 done wrong

[Ian Lance Taylor]

doctor electron <address@hidden> writes:

> 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.

We would discard the ABI in a second if the benefit exceeds the cost.

What benefit would we gain by changing the definition of R_386_PC32?
You have not described any benefit beyond abstract appeals to what you
think object files should look like.  That doesn't count.  Give us a
measurable benefit and we'll consider it.  A vague hand-waving notion
of how you think it should work means nothing.  A complaint that the
current ELF ABI makes it harder to convert PE/COFF object files to ELF
means nothing; it's already hard to do that conversion.

> 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.

Supporting lazy compiler writers is not a benefit.

> 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.

Changing this would not permit interoperability of .obj files.  There
are many other issues to consider.  This one is quite minor compared
to others.  Therefore, this is not a benefit.

> 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.

Nobody said the ABI is written in stone.  We said that we follow the
ABI, and we do that for a reason, and there is a cost to changing.
You have not demonstrated any meaningful benefit to changing.

> 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).

You are confused.  Since Microsoft does not generate ELF files, they
use a different ABI, specifically the PE/COFF ABI which is available
from MSDN.  That ABI specifies a different handling for PC relative
relocations.  I assure you that Microsoft follows the PE/COFF ABI just
as rigorously as we follow the ELF ABI.

Ian