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 _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
