Subject: Re: -current MIPS ld.elf_so fix/workaround
To: Charles M. Hannum <>
From: Rafal Boni <>
List: tech-toolchain
Date: 04/14/2003 13:29:05
In message <>, you write: 

-> On Mon, 2003-04-14 at 04:40, Christopher SEKIYA wrote:
-> > On Sun, Apr 13, 2003 at 12:55:27PM -0400, Rafal Boni wrote:
-> > 
-> > > I'm not sure which binutils versions generate the correct output accordi
-> ng
-> > > to the comment and which ones don't -- other than the fact that it appea
-> rs
-> > > that the current in-tree one does not).
-> > 
-> > After a quick test, I agree.  Removing the "broken" conditional (per the f
-> irst
-> > hunk of your patch) indicates that SUPPORT_OLD_BROKEN_LD should actually
-> I think y'all need to read the comments in there to understand what's
-> going on a bit.  That code had the "broken" conditional because it
-> entirely defeats lazy binding, and so is not very attractive for general
-> use.

Right, I do realize it's defeating lazy binding, but I'd rather have a
runtime linker that works right than one that is fast but doesn't work
correctly 8-)

In the perfect world, all we'd need to do is find a better heuristic to
catch those -- I'm guessing your heuristic for setting "broken" was a
good one to identify old-old libraries which had the problem I found
back in October, 2001 but not so well for identifying the newer issue
of "pointers to functions resolved incorrectly".

ISTM that to find this new b0rken-ness you found, one would have to
figure out the "broken" state based on the main object, and pass that
in to the fixup handlers for the shared objects...

-> The problem you're running into (which I documented a while back, and
-> asked for help from some MIPS binutils g00r00s) has to do with the use
-> of function pointers.  IIRC, function pointers in MIPS executables are
-> being resolved directly to the function, if the function exists in the
-> executable, but function pointers in shared libraries are being resolved
-> to the library's PLT slot.  This is causing the pointers to compare
-> incorrectly, which in turn causes some random lossage (e.g. libXt
-> doesn't work so well in some cases).

Right, this matches my experience... But it seems to be that even our
newest toolchain still generates this b0rken state and ld.elf_so does
not catch it.

Do you actually have (ie, have you played with) a version of binutils
that *doesn't* exhibit this problem?  Has it been fixed in more recent
binutils versions?

[ snipped re: the more-obviously incorrect bit of my patch...]


Rafal Boni                                           
  We are all worms.  But I do believe I am a glowworm.  -- Winston Churchill