Re: glibc's use of gnu_indirect_function feature - is it backwardscompatible?

[Bryan Ischo <bryan at ischo dot com>]

On 08/10/11 19:20, Carlos O'Donell wrote:
> On 8/10/2011 10:12 PM, Bryan Ischo wrote:
> > Just looking for confirmation that if I, say, patch my binutils to
> > leave the ABI identification alone even if the object "has gnu
> > symbols" (in binutils parliance), can I expect things to "just
> > work"?
> No. It's not "backwards compatibility" it's actually "forwards
> compatbility" that you need. You want to run a new binary or
> library with an old linker. It isn't going to work.

I think of it as glibc having backwards compatibility with older linkers 
and loaders, but you could look the other way around too.  You say 
potato, I say potahto :)

> Yes, glibc and ld.so must be updated together, they are absolutely
> dependent on each other.
>
> I strongly suggest simply implementing STT_GNU_IFUNC support
> for your target, it's not that difficult. If you can't implement
> STT_GNU_IFUNC support, perhaps because your "secret" target
> prevents it, then stay with an old glibc.
>
> What problem are you trying to solve in the first place that
> you need to upgrade glibc?

Where I work we have a standard build environment encapsulated as a 
chroot filesystem and it has really, really old tools.  Like, 7 - 10 
years old.  I am trying to evaluate the newest version of glibc in this 
environment, to get an idea of whether or not the MIPS ABI enhancements 
that were introduced in GCC 4.4 (I think that was the version) are 
likely to have enough payoff for us to switch to the new toolchain.  I 
was trying very hard to bootstrap binutils, gcc, and glibc in this 
ancient environment just for evaluation purposes; if the gain is big I 
am sure that our tools team would accept taking on the work of updating 
the standard build environment to support the new compiler.  This is not 
a trivial task as it requires hundreds of developers to upgrade.

But in the meantime, I am trying to evaluate the tools in the current 
environment and bootstrapping the toolchain has been quite a challenge.  
I finally got it all to compile and produce the toolchain but I noticed 
that the libc.so and libm.so that are produced have this GNU/Linux ABI 
that isn't compatible with the runtime environment.  It's the last 
hurdle after a series of incredible hurdles and I really wish I could 
just jump over this last one ...

I suspect that what I will do is to patch glibc locally to disable its 
use of gnu_indirect_function.  I have invested too much effort into 
getting this exact version of gcc, glibc, and binutils compiled in this 
environment to switch to different versions right now.

Thank you,
Bryan