glibc's use of gnu_indirect_function feature - is it backwards compatible?
Bryan Ischo
bryan@ischo.com
Thu Aug 11 02:12:00 GMT 2011
Hi there. I have a unique environment with a runtime ld.so that doesn't
know anything about gnu indirect functions, but am trying to build a
glibc version 2.13 to run on it. A problem that I am having is that the
resulting libc shared object library has an ABI type of "GNU/Linux"
instead of SYSV. My loader will not load such libaries, and so I've
researched ways to demote this libc to SYSV.
I should mention that the runtime is an i686 system
(i686-unknown-linux-gnu).
I believe I understand the cause of the libc's ABI being set to
GNU/Linux - it's because it includes "gnu indirect functions" and those
require the new ABI, so the linker emits it.
What I don't understand is whether or not these indirect functions are
backwards compatible with old linkers. If I just rewrite the ABI
version on the library to SYSV, will my ld.so (version 2.2.5) be able to
use it? As an example, consider the strstr function. glibc implements
a bunch of special magic that creates a strstr_ifunc and then somehow
rigs it up to be used as an indirect function in place of strstr
(right?). Does this magic include some kind of fallback implementation
that older loaders see and understand that just goes straight to the old
strstr implementation?
I've tried my hardest to disable gnu indirect functions but they seem
deeply embedded in the toolchain (only gcc lets you turn them off,
although that has little effect on glibc which uses them regardless of
what the assember or compiler supports). The fact that glibc emits them
no matter what the assembler or compiler supports leads me to believe
that what is being emitted by glibc is backwards compatible; otherwise,
glibc would have a hidden dependency on the linker and loader versions
that it doesn't explicitly state, and I doubt that the glibc developers
would do something that insidious.
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"?
Thanks!
Bryan
More information about the Libc-help
mailing list