RE: Distributions still suffering from s390 ABI change problems.

[Matthew Fortune <Matthew dot Fortune at imgtec dot com>]

Carlos O'Donell <carlos@redhat.com>writes:
> 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.

The extent to which ABI checking can be generalized is limited in
my opinion but the framework to allow architecture dependent decisions
to be made, based on the content of a loadable section, can obviously
be shared. I will be hoping to commit such work in the coming weeks.
I'm happy to copy over the glibc aspects of the spec to the glibc
wiki and could separate out the part which can be shared. I won't be
able to do this in the next few days though I'm afraid.

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

The MIPS ABI is not suffering from a jmp_buf change but the issues are
at least as complex as changing jmp_buf. Exactly how the tooling
detects and marks objects is one of the aspects of this that is likely
to be architecture dependent IMO. You could of course argue that having
generic support for handling a change in jmp_buf size could benefit
multiple architectures so warrants specific support but given the scope
that an 'ABI' encompasses the overall definition of a compatible ABI
is always going to be arch specific even if some aspects are common.
Personally I would want to avoid a generalized solution that does not
leave scope for arbitrary arch specific rules.

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

My head is a little too full of the MIPS ABI problems to think this
through properly but I agree that 'don't care' settings are quite
important when trying to limit the impact of a change like this.

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

Yes. The code to achieve this throughout the tooling runs easily into
hundreds of lines of code and tests into the thousands of lines. My
opinion is that the effort to document/specify these things is harder
to write than the code though.

Matthew