glibc's use of gnu_indirect_function feature - is it backwards compatible?
Bryan Ischo
bryan@ischo.com
Thu Aug 11 02:33:00 GMT 2011
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
More information about the Libc-help
mailing list