Reverting the s390 jmp_buf/ucontext_t ABI change

[Stefan Liebler]

Hi,

we have still some issues with the revert-patch.
Trying to create a symbol versioning of one function (e.g. __setjmp)
with the same name leads to linker errors:
"libc_pic.a(setjmp.os):(*IND*+0x0): multiple definition of `__setjmp'
libc_pic.a(setjmp.os):(.text+0x10): first defined here"

Declaring the original function as weak (like the BSD-functions of 
setjmp) resolves the linker error.
The resulting versionized symbols are strong.

Here is an example for __setjmp:
#if !defined IS_IN_rtld
# if defined SHARED
#  if SHLIB_COMPAT (libc, GLIBC_2_19, GLIBC_2_20)
weak_extern (__setjmp);
strong_alias (__setjmp, __v1__setjmp);
strong_alias (__setjmp, __v2__setjmp);
versioned_symbol (libc, __v1__setjmp, __setjmp, GLIBC_2_0);
compat_symbol (libc, __v2__setjmp, __setjmp, GLIBC_2_19);
#  endif
# endif
#endif

and the resulting nm setjmp/setjmp.os:
0000000000000008 T __GI__setjmp
0000000000000010 W __setjmp
0000000000000010 T __setjmp@@GLIBC_2.2
0000000000000010 T __setjmp@GLIBC_2.19
                  U __sigjmp_save
0000000000000018 W __sigsetjmp
0000000000000018 T __sigsetjmp@@GLIBC_2.2
0000000000000018 T __sigsetjmp@GLIBC_2.19
0000000000000010 T __v1__setjmp
0000000000000018 T __v1__sigsetjmp
0000000000000008 T __v1_setjmp
0000000000000000 T __v1setjmp
0000000000000010 T __v2__setjmp
0000000000000018 T __v2__sigsetjmp
0000000000000008 T __v2_setjmp
0000000000000000 T __v2setjmp
0000000000000008 W _setjmp
0000000000000008 T _setjmp@@GLIBC_2.2
0000000000000008 T _setjmp@GLIBC_2.19
0000000000000000 W setjmp
0000000000000000 T setjmp@@GLIBC_2.2
0000000000000000 T setjmp@GLIBC_2.19

This produces the correct symbol-versions for __setjmp@@GLIBC_2.2
and __setjmp@GLIBC_2.19.
Is this ok or do you have better ideas?



Another question is about GLIBC_PRIVATE symbols.
Is it ok if these symbols are omitted by this patch?
Those symbols were introduced by the original patch and are used by 
libpthread.

Bye

On 07/22/2014 04:41 PM, Ulrich Weigand wrote:
> Hello,
>
> as has been discussed on this list recently, glibc 2.19 contained a change
> in the size of jmp_buf and ucontext_t on s390/s390x to reserve space for
> future extensions.
>
> Back when we made that decision, it was done deliberately even though we were
> aware that there was a theoretical possibility this change could affect some
> old binaries; however, we originally thought this would be a rare occurrence
> and would not apply to any of the binaries anyone actually cared about.
>
> As the fallout has now shown, unfortunately that assumption was mistaken.
> I'm sorry for the problems this has caused, in particular for the distros.
>
> Given the fallout, and after many discussions with affected parties, we have
> now come to the conclusion that the best way forward is to revert that change.
>
> This means that we'll just have to live with the fact that any new registers
> on future generations of the architecture will have to remain call-clobbered
> in the ABI.
>
> The next question is, how to move forward and actually do the reversion
> without creating new problems in the process.  In particular, any binary
> already built against the 2.19 glibc may contain references to e.g setjmp
> at the GLIBC_2.19 symbol version level; a plain revert of Andreas' patch
> will then prevent those programs from even starting.
>
> The current thought is to revert the patch, and then add a new GLIBC_2.19
> symbol version of setjmp (and the other affected symbols), pointing straight
> to the same implementation as the old setjmp symbol.  Given that new callers
> will simply provide a too-big buffer to setjmp, that should just work.
>
> [ Of course, any applications/libraries out there that embed jmp_buf or
> ucontext_t in an ABI-relevant data structure that have already been rebuilt
> against 2.19 headers will have to rebuilt again; this is necessary in any
> case to revert the breakage in their ABI caused by the glibc change. ]
>
> Stefan Liebler is working on a patch implementing this, and will post it
> ASAP for approval and inclusion in 2.20.  A backport of that patch to 2.19
> will also be provided, and probably ought to be included in the 2.19
> release branch -- declaring the original 2.19 implementation as a bug
> that needs to be fixed.  Any distro already shipping 2.19 should also
> include the patch (and rebuild affected binaries as necessary).
>
> If you see any problems with this approach, please let us know.
>
> Bye,
> Ulrich
>
>
> P.S.: Unfortunately, Andreas Krebbel is currently on leave and not following
> the lists on a daily basis.  I did contact him, and he agrees with reverting
> his patch as the way forward.
>