This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Wed, Aug 10, 2011 at 10:33 PM, Bryan Ischo <bryan@ischo.com> wrote:
> 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 :)

All joking aside, it's not at all like that. You must not use a newer
glibc with an older dynamic linker, it simply isn't supported.

>> 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.

OK, so why didn't you upgrade the dynamic linker when you rebuilt glibc?

> 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 ...

Yes, it is *very* challenging.

MIPS is also pretty bad.

However, STT_GNU_IFUNC is not a hurdle, just upgrade the dynamic
loader and you'll be done.

> 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.

No, what you really need to do is build glibc and upgrade all the
pieces it controls e.g. libc, libm, various static pieces used in
linking both static and shared programs, and ld.so.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]