elf32-mips breaks binary compatibility

elf32-mips breaks binary compatibility

[Ralf Baechle]

Hi,

the current elf32-mips.c fixes an ancient bug in how relocations in glibc
are being computed.  The bad thing is that this breaks binary compatibility
with for dynamic objects generated by older linkers like binutils 2.8.1.
So far this went unnoticed because the problem got compensated by an
equivalent hack in glibc's dynamic linker, so this bug is by now probably
not only well established for Linux/MIPS systems but probably OpenBSD and
NetBSD as well ...

The problem: when generating references to global symbols old linkers have
not added the symbols value to the field being relocated in the linker
output.  That means for example for

	.globl	var
var:	.word	var + 0x1234

ld would have emited a 32-bit word with the value 0x1234 into output file
while current ld would emit 0x1234 + actual address of var into the
linker output.  Note that this bug affects only ELF shared library
generation; normal executables alway had been ok.

(And this made a few programs dump core because the equivalent bug in the
GNU libc dynamic linker affected all binaries, not just DSOs ...)

Right now I'm working on changing the current linker to tag all binaries
such that the dynamic linker can recognice them and do the right thing.
Mark has suggested using a DT_MIPS_LINUX_VERSION tag.  I'm a bit
reluctant to allocate such a new DT_ tag because MIPS / SGI are using them
for all sorts of purposes and I want to avoid a future clash.  So my
proposal which is a bit hackish would be to use the DT_MIPS_TIME_STAMP
tag with a special magic time stamp.  I've choosen the value 11717580
which is equivalent to a date in 1970, therfore should never ever be
generated in a binary generated by a SGI linker; current GNU linkers don't
emit this tag at all.  Comments?

Following below a patch which does the wrong thing and reintroduces the
wrong behaviour into current bfd and a short piece of code which
demonstrates the difference in the linker output.

  Ralf

Index: binutils-cygnus/bfd/elf32-mips.c
===================================================================
RCS file: /cvs/binutils/binutils/bfd/elf32-mips.c,v
retrieving revision 1.49
diff -u -r1.49 elf32-mips.c
--- elf32-mips.c	1999/08/15 22:56:20	1.49
+++ elf32-mips.c	1999/08/16 00:24:31
@@ -5658,7 +5661,6 @@
   else
     {
       long indx;
-      bfd_vma section_offset;
 
       /* We must now calculate the dynamic symbol table index to use
 	 in the relocation.  */
@@ -5685,23 +5687,12 @@
 		abort ();
 	    }
 
-	  /* Figure out how far the target of the relocation is from
-	     the beginning of its section.  */
-	  section_offset = symbol - sec->output_section->vma;
 	  /* The relocation we're building is section-relative.
 	     Therefore, the original addend must be adjusted by the
 	     section offset.  */
-	  *addendp += symbol - sec->output_section->vma;
-	  /* Now, the relocation is just against the section.  */
-	  symbol = sec->output_section->vma;
+	  *addendp += symbol;
 	}
-      
-      /* If the relocation was previously an absolute relocation, we
-	 must adjust it by the value we give it in the dynamic symbol
-	 table.  */
-      if (r_type != R_MIPS_REL32)
-	*addendp += symbol;
-
+ 
       /* The relocation is always an REL32 relocation because we don't
 	 know where the shared library will wind up at load-time.  */
       outrel.r_info = ELF32_R_INFO (indx, R_MIPS_REL32);

begin 664 nuke-ld-13.tar.gz
M'XL("(D!KC<"`VYU:V4M;&0M,3,N=&%R`.W6SVO;,!0'<%^MO^(=<M@.\F1;
MMB!06$<.8[1K8>RP2T&QY%:M(@7+IMU_/]NX35)8>VGZ([P/Q(KT!%)X?(-=
M=Z.I533-OT3[`IP)44`$`*+D.^.$`92BR#EC15D"I$RP-((B>@5=:&4#$#72
MUD_M>Z[^0;E-_T_EC:Z-U2]^1LI8R?G_^\_[XMC_7&2Y&/J?\:R(@&'_]^[X
M%QS!RJP#M<9U=U0&<K+87;**G'W[L?A]>KZ[[I?7JENM"9'6SL&:94B")R0Y
M_W[V\\]F81KG$-+$0\@23^+9IY/%9Z#A2C9:`?4P^PJSBV%].JDO4O77R96I
M:*.MK_H=C\I!5ZWQ[BA1LI7]O.ZLI95WK79M&+8_W*2R6CI0)K3C-_)H/B<Q
M;59`Z_LK;VX*E6\TB0[85O[['QSV<L9S^4]3,>6_+/,R&Q:X8)C_UQ`G?CW$
M*%Z;*B,D'M,TC)?6+VU<-WY)AL<\3FY]H^+:^ZUJ/^D_]S6>'714#C[_Z1OE
M'X9WOBG_F1!C_@N!^7\'^5?>N$LR/K?_`3`W""&$$$(((8000@@AA!!""+U'
*_P`Y[-W<`"@`````
`
end

Re: elf32-mips breaks binary compatibility

[Ian Lance Taylor]

   Date: Mon, 16 Aug 1999 12:19:31 +0200
   From: Ralf Baechle <ralf@uni-koblenz.de>

   The problem: when generating references to global symbols old linkers have
   not added the symbols value to the field being relocated in the linker
   output.  That means for example for

	   .globl	var
   var:	.word	var + 0x1234

   ld would have emited a 32-bit word with the value 0x1234 into output file
   while current ld would emit 0x1234 + actual address of var into the
   linker output.  Note that this bug affects only ELF shared library
   generation; normal executables alway had been ok.

   (And this made a few programs dump core because the equivalent bug in the
   GNU libc dynamic linker affected all binaries, not just DSOs ...)

   Right now I'm working on changing the current linker to tag all binaries
   such that the dynamic linker can recognice them and do the right thing.
   Mark has suggested using a DT_MIPS_LINUX_VERSION tag.  I'm a bit
   reluctant to allocate such a new DT_ tag because MIPS / SGI are using them
   for all sorts of purposes and I want to avoid a future clash.  So my
   proposal which is a bit hackish would be to use the DT_MIPS_TIME_STAMP
   tag with a special magic time stamp.  I've choosen the value 11717580
   which is equivalent to a date in 1970, therfore should never ever be
   generated in a binary generated by a SGI linker; current GNU linkers don't
   emit this tag at all.  Comments?

Basically, it sounds like we need some mechanism we can use to
distinguish old, incorrect, shared libraries from new, correct shared
libraries.

I'm not completely clear on what you are proposing.  Are you proposing
a dynamic tag which will only be used on old, incorrect, shared
libraries?  In other words, a tag which we will eventually be able to
dispense with completely?

If so, then I don't think it matters too much what you use.  If you
use DT_MIPS_LINUX_VERSION, then assign it a large number, much larger
than is likely to conflict with any future DT_MIPS_* tag.  However, I
think your DT_MIPS_TIME_STAMP suggestion is also reasonable.

Ian

Re: elf32-mips breaks binary compatibility

[Jakub Jelinek]

> Right now I'm working on changing the current linker to tag all binaries
> such that the dynamic linker can recognice them and do the right thing.
> Mark has suggested using a DT_MIPS_LINUX_VERSION tag.  I'm a bit
> reluctant to allocate such a new DT_ tag because MIPS / SGI are using them
> for all sorts of purposes and I want to avoid a future clash.  So my
> proposal which is a bit hackish would be to use the DT_MIPS_TIME_STAMP
> tag with a special magic time stamp.  I've choosen the value 11717580
> which is equivalent to a date in 1970, therfore should never ever be
> generated in a binary generated by a SGI linker; current GNU linkers don't
> emit this tag at all.  Comments?

With timestamp I see the problem what if quickstart is implemented in
binutils (I still would like to give it a shot on sparc64 to see if the
performance boost is worth the trouble), in which case we'll need to use
DT_MIPS_TIME_STAMP...
So IMHO DT_MIPS_LINUX_VERSION would not be very bad solution. And you could
speak with SGI to leave that number for you in the specs.

Cheers,
    Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
UltraLinux  |  http://ultra.linux.cz/  |  http://ultra.penguin.cz/
Linux version 2.3.13 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________

Re: elf32-mips breaks binary compatibility

[Ian Lance Taylor]

   Date: Tue, 17 Aug 1999 08:06:33 +0200
   From: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>

   > Right now I'm working on changing the current linker to tag all binaries
   > such that the dynamic linker can recognice them and do the right thing.
   > Mark has suggested using a DT_MIPS_LINUX_VERSION tag.  I'm a bit
   > reluctant to allocate such a new DT_ tag because MIPS / SGI are using them
   > for all sorts of purposes and I want to avoid a future clash.  So my
   > proposal which is a bit hackish would be to use the DT_MIPS_TIME_STAMP
   > tag with a special magic time stamp.  I've choosen the value 11717580
   > which is equivalent to a date in 1970, therfore should never ever be
   > generated in a binary generated by a SGI linker; current GNU linkers don't
   > emit this tag at all.  Comments?

   With timestamp I see the problem what if quickstart is implemented in
   binutils (I still would like to give it a shot on sparc64 to see if the
   performance boost is worth the trouble), in which case we'll need to use
   DT_MIPS_TIME_STAMP...

Yes, but the argument is that it will never have a date in 1970, and
that only that date will trigger special behaviour by the dynamic
linker.

Ian

Re: elf32-mips breaks binary compatibility

[H.J. Lu]

> 
> > Right now I'm working on changing the current linker to tag all binaries
> > such that the dynamic linker can recognice them and do the right thing.
> > Mark has suggested using a DT_MIPS_LINUX_VERSION tag.  I'm a bit
> > reluctant to allocate such a new DT_ tag because MIPS / SGI are using them
> > for all sorts of purposes and I want to avoid a future clash.  So my
> > proposal which is a bit hackish would be to use the DT_MIPS_TIME_STAMP
> > tag with a special magic time stamp.  I've choosen the value 11717580
> > which is equivalent to a date in 1970, therfore should never ever be
> > generated in a binary generated by a SGI linker; current GNU linkers don't
> > emit this tag at all.  Comments?
> 
> With timestamp I see the problem what if quickstart is implemented in
> binutils (I still would like to give it a shot on sparc64 to see if the
> performance boost is worth the trouble), in which case we'll need to use
> DT_MIPS_TIME_STAMP...
> So IMHO DT_MIPS_LINUX_VERSION would not be very bad solution. And you could
> speak with SGI to leave that number for you in the specs.
> 

We had to deal with it on Alpha. That is why glibc 2.1 is libc.so.6.1
on alpha. Why cannot MIPS do the same? Glibc can require certain
version of binutils and use libc.so.6.1 for soname on MIPS.



H.J.

Re: elf32-mips breaks binary compatibility

[Jakub Jelinek]

On Tue, Aug 17, 1999 at 02:11:01AM -0400, Ian Lance Taylor wrote:
>    Date: Tue, 17 Aug 1999 08:06:33 +0200
>    From: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>
> 
>    > Right now I'm working on changing the current linker to tag all binaries
>    > such that the dynamic linker can recognice them and do the right thing.
>    > Mark has suggested using a DT_MIPS_LINUX_VERSION tag.  I'm a bit
>    > reluctant to allocate such a new DT_ tag because MIPS / SGI are using them
>    > for all sorts of purposes and I want to avoid a future clash.  So my
>    > proposal which is a bit hackish would be to use the DT_MIPS_TIME_STAMP
>    > tag with a special magic time stamp.  I've choosen the value 11717580
>    > which is equivalent to a date in 1970, therfore should never ever be
>    > generated in a binary generated by a SGI linker; current GNU linkers don't
>    > emit this tag at all.  Comments?
> 
>    With timestamp I see the problem what if quickstart is implemented in
>    binutils (I still would like to give it a shot on sparc64 to see if the
>    performance boost is worth the trouble), in which case we'll need to use
>    DT_MIPS_TIME_STAMP...
> 
> Yes, but the argument is that it will never have a date in 1970, and
> that only that date will trigger special behaviour by the dynamic
> linker.

I understood Ralf wants to tag the new binaries with the tag, as tagging the
old ones would mean ldconfig or some other binary walking on all shared
libraries has to tag some of the libraries (or all of them provided the user
is sure he does not have any newly compiled library).

Cheers,
    Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
UltraLinux  |  http://ultra.linux.cz/  |  http://ultra.penguin.cz/
Linux version 2.3.13 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________

Re: elf32-mips breaks binary compatibility

[Ian Lance Taylor]

   Date: Tue, 17 Aug 1999 10:26:11 +0200
   From: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>

   I understood Ralf wants to tag the new binaries with the tag, as tagging the
   old ones would mean ldconfig or some other binary walking on all shared
   libraries has to tag some of the libraries (or all of them provided the user
   is sure he does not have any newly compiled library).

I agree that tagging the new binaries raises many issues.  I assumed
that he meant to tag the old binaries.  Ralf, which approach were you
suggesting?

Ian

Re: elf32-mips breaks binary compatibility

[Ralf Baechle]

On Tue, Aug 17, 1999 at 02:11:01AM -0400, Ian Lance Taylor wrote:

> Yes, but the argument is that it will never have a date in 1970, and
> that only that date will trigger special behaviour by the dynamic
> linker.

It's impractical to tag old binaries, so therefore we have to tag new
ones.  So if Jakub goes and actually implements some Quickstart like
mechanism not both can use this tag at the same time.

I think I have some better mechanism for the dynamic linker to detect
this problem without any tag at all.  I'll work on that tomorrow and
checkout if it's actually implementable.

  Ralf

Re: elf32-mips breaks binary compatibility

[Ian Lance Taylor]

   Date: Wed, 18 Aug 1999 00:11:33 +0200
   From: Ralf Baechle <ralf@uni-koblenz.de>

   It's impractical to tag old binaries, so therefore we have to tag new
   ones.  So if Jakub goes and actually implements some Quickstart like
   mechanism not both can use this tag at the same time.

OK.  I think we need to talk about this further if we plan to tag new
binaries.  That would put us in the position of adding the new tag
forever.  It would also mean that we could never support existing SGI
MIPS/ELF shared libraries.  Certainly using DT_MIPS_TIME_STAMP is
inappropriate if we are tagging new binaries.

   I think I have some better mechanism for the dynamic linker to detect
   this problem without any tag at all.  I'll work on that tomorrow and
   checkout if it's actually implementable.

That would be ideal.

Ian

Re: elf32-mips breaks binary compatibility

[Ralf Baechle]

On Mon, Aug 16, 1999 at 11:12:25PM -0700, H.J. Lu wrote:

> We had to deal with it on Alpha. That is why glibc 2.1 is libc.so.6.1
> on alpha. Why cannot MIPS do the same? Glibc can require certain
> version of binutils and use libc.so.6.1 for soname on MIPS.

Using some detection mechanism in the dynamic linker allows me to
arbitrarily mix both flavours of binaries.  Especially we'll never have
to have two copies of libc in memory is it might be necessary with
a new major number.

  Ralf

Re: elf32-mips breaks binary compatibility

[Ralf Baechle]

On Tue, Aug 17, 1999 at 06:16:25PM -0400, Ian Lance Taylor wrote:

>    It's impractical to tag old binaries, so therefore we have to tag new
>    ones.  So if Jakub goes and actually implements some Quickstart like
>    mechanism not both can use this tag at the same time.
> 
> OK.  I think we need to talk about this further if we plan to tag new
> binaries.  That would put us in the position of adding the new tag
> forever.  It would also mean that we could never support existing SGI
> MIPS/ELF shared libraries.  Certainly using DT_MIPS_TIME_STAMP is
> inappropriate if we are tagging new binaries.
> 
>    I think I have some better mechanism for the dynamic linker to detect
>    this problem without any tag at all.  I'll work on that tomorrow and
>    checkout if it's actually implementable.
> 
> That would be ideal.

I dumped above mentioned idea for something even simpler.  GNU binutils
reseverve two entries in the GOT.  Both old and new versions set 
got[1] = 0x80000000 to mark binaries build by GNU binutils.  We can
extend that and use another bit to mark new executables.  Detection then
is trivial like

  goodelf = ((got[1] & 0x80000000) == 0
             || (got[1] & 0xc0000000) == 0xc0000000);

  Ralf