Re: elf32-mips breaks binary compatibility

[Ian Lance Taylor <ian@zembu.com>]

   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