Long, long ago, Eric Botcazou, a life form in far off space, emitted: >> If so, the market will decide; is a corrected ld favored or not. > >It's already decided: your proposed change would break the ABI, hence break >binary compatibility by definition.
The ABI states linkers cannot make -4 themselves, they have to read it from a file? Heck, let's break it! What are we waiting for? I agree it's "already decided". Last time I looked, Linux and the others mentioned in this thread have well less than 10% market share both for number of computer users and number of computers. That percent can improve if upgrading quality was more important than some document written a generation ago. Fact: ld fails to rel reloc a .text section location if it does not contain -4. This fact == low quality. >> That's the marvel. Why was this not corrected 20 years ago? > >Because, if you really think about it, the current definition of R_386_PC32 is >the right one. I gave the current definition in my previous emails (the only valid one is based on how microprocessors work) and yet ld fails to link as stated above. [hint: microprocessors don't know what we are saying or what ABI says; ld has no need whatsoever to get -4 from input files; ld writers should know that.] >Again, it's not Linux, the i386 ABI predates Linux, Linux only conformed to >the existing ABI. ABI again? Are you saying ABI doesn't know how to do rel relocs? Again, the location must contain the offset to the symbol from the current contents of the CPU eip register. Are you saying ABI contradicts that? What exactly does ABI have to do with ld's failure to do rel reloc? Or are you saying, ld should fail? I say, why? Why not do it right? Success is not as bad as it might seem! ;) j _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
