Re: Relocation bug

[Daniel Jacobowitz <dan at debian dot org>]

On Sun, Feb 23, 2003 at 04:53:11PM +0100, Ralf Baechle wrote:
> On Sat, Feb 22, 2003 at 07:05:55PM -0800, Eric Christopher wrote:
> 
> > This patch:
> > 
> > http://sources.redhat.com/ml/binutils/2001-01/msg00290.html
> > 
> > is the one that changed the behavior to what it is currently. It was a
> > revert of one of Ralf's patches to which he was cc'd on the mail. From a
> > quick look it appears correct, however, I can't find any reasoning other
> > than "ABI Compliance" in the patch.
> 
> The ABI document (as mentioned a dozen times off the list) is pretty badly
> written.  This I think how both Maciej, myself and others got lured into
> believing wrong is right and right is wrong.
> 
> The ABI describes the two relocation as follows:
> 
>   R_MIPS_32      2 T word32 external S + A
>                  2 T word32 local    S + A
>   R_MIPS_REL32   3 T word32 external A - EA + S
>   R_MIPS_REL32   3 T word32 local    A - EA + S
> 
> You see both relocations against both local and external symbols need to
> perform the same calculation.  What was missed what the definition of the
> S operand scattered throughout the document a few pages away:
> 
>   S Represents the value of the symbol whose index resides in the relocation
>     entry, unless the the symbol is STB_LOCAL and is of type STT_SECTION in
>     which case S represents the original sh_addr minus the final sh_addr
> 
> There's two issues with that paragraph:
> 
>  - "original sh_addr minus the final sh_addr" is wrong and wouldn't result
>    in a functioning static linker / dynamic linker.  "final sh_addr minus
>    original sh_addr" would be correct.  The 64-bit ABI corrects this
>    mistake.

Yes, Eric and I worked this out last night.

>  - People did simply miss this paragraph not noting that the S operand has
>    different definitions for two cases.  This in the end is what this bug
>    is about and indeed one of the people I was did discuss this with in
>    private got caught by this interpretation.
> 
> Now only that I recently had to revisit the issue after quite a while I
> understood what was going on; the usual comparision with the IRIX linker
> supports my theory.

> Maciej agrees that this is wrong behaviour.

But what are you proposing to do about it?  H.J.'s patch is
unacceptable at this extremely late date.

> It also means the binutils ABI MIPS ELF and MIPS IRIX ELF targets are
> broken resulting in 1) break support for those binary flavours and 2)
> in combination with the matching OpenBSD and GNU Libc bugs somewhat
> establishing two new minimally different but incompatible binary
> flavours.  As for Linux both flavours are currently actively being
> shipped by vendors.  It's simply not yet caused major yelling because
> most users are not swapping swapping binaries around.  It's a bloddy
> mess and I'm trying to stop it before it gets worse.

I'm curious.  Name a Linux vendor shipping the previous ABI, the one
you want to revert to?  Only person I know still using tools that old
is you.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer