[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: BUG elf32-i386 R_386_PC32 done wrong

From: doctor electron
Subject: Re: BUG elf32-i386 R_386_PC32 done wrong
Date: Sat, 24 Jun 2006 15:40:06 -0500

Long, long ago, Eric Botcazou, a life form in far off space,

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]