This is the mail archive of the libc-alpha@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: Distributions still suffering from s390 ABI change problems.


Carlos O'Donell <carlos@redhat.com> writes:
> On 07/14/2014 05:09 PM, David Miller wrote:
> > Therefore, on the negative side, we might be stuck with this.  But, on
> > the positive side, we can refer to this incident next time a similar
> > incident arises.  We now know exactly what the ramifications are for
> > not handling this properly.
> 
> OK, so I just tried a SO name bump on x86-64 and all hell breaks loose.
> 
> It's unsupportable as a solution for glibc.
> 
> The SO name bump in a mixed-ABI environment like debian results in two
> libc's being loaded and competing for effectively the same namespace
> of symbols with resolution (and therefore selection of the ABI) being
> determined by ELF interposition and scope rules. It's a nightmare.
> It's possible a worse solution than just telling everyone to rebuild
> and get on with their lives.
> 
> Should we have done something like this instead:
> 
> * Add an s390 .gnu.attributes tag for the jmp_buf ABI change.
> * Enforce the ABI at the linker level so you can't link old and
>   new objects, like is done by ARM with hard vs. soft fp.
> * Make .gnu.attributes loadable (SEC_ALLOC) like proposed once
>   by H.J. and put it somewhere with other loaded read-only
>   data (minimize mmap calls).
> * Have the dynamic loader do a check as it loads objects to
>   ensure their ABI matches via an s390 specific function that
>   knows which .gnu.attributes are ABI special and compares them
>   to the presently assembled ABI (a little extra execute code
>   per DSO load).
> 
> Thoughts?

I wondered when this might come up... For a variety of reasons the
loadable .gnu_attributes section is undesirable but the concept of
improving dynamic link checking is undeniably valuable. MIPS is
making this transition right now to have ABI information made
available as a loadable section and get some relatively strict
checks in place to ensure only compatible objects are loaded.

The original glibc thread is here (although things have moved on
since then):
http://sourceware.org/ml/libc-alpha/2014-05/msg00044.html
With significant discussion also on both GCC and binutils lists.

This work for MIPS is entering the final stages of development and
testing. Some of the infrastructure put in place may be of use either
directly or as reference should any other arch want to adopt it.

A key feature though is to ensure the EI_ABIVERSION is bumped in
executables/libraries which need special handling. I'm sure someone
could concoct a way of preventing objects that use the new jmpbuf
size from being linkable with old static linkers and ensure that
new linkers bump the EI_ABIVERSION when the new jmpbuf is
encountered. A new dynamic linker can then deal with checking for
compatible objects using new loadable information.

> Several people have been considering extended .gnu.attributes
> to the dynamic loader, but there wasn't any real impetus,
> perhaps until now.

I won't re-state the issues with/cost of loading .gnu.attributes
but there are a variety of threads on the topic.

Matthew


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