Re: Distributions still suffering from s390 ABI change problems.

["Carlos O'Donell" <carlos at redhat dot com>]

On 07/15/2014 03:58 AM, Matthew Fortune wrote:
> 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.

Could you write up something on the glibc wiki that describes
this work in general? I'd like to see *something* generalized
such that we can reuse it for strict runtime ABI checking.

In particular I'd like to know how coarse grained the checking
is, and if for example if none of your exported symbols have
say jmp_buf in their types then there is no reason to add the
jmp_buf ABI tag to the list of tags such a system would create.

Even better would be to add the jmp_buf ABI tag, indicating you
knew about it, but mark it "don't care" since none of the API
depends on it (or allow relaxed checking e.g. unset ABI tag is
compatible with a set ABI tag).

This obviously requires compiler help to take source annotations
and turn them into object annotations if public functions have
a type with a tag appear in it's argument list.

Cheers,
Carlos.