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: Reverting the s390 jmp_buf/ucontext_t ABI change


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.



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