This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Reverting the s390 jmp_buf/ucontext_t ABI change
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Cc: krebbel at linux dot vnet dot ibm dot com, stli at linux dot vnet dot ibm dot com, arnez at linux dot vnet dot ibm dot com, schwidefsky at de dot ibm dot com, carlos at redhat dot com, davem at davemloft dot net, aurelien at aurel32 dot net, siddhesh at redhat dot com, allan at archlinux dot org, richard dot guenther at gmail dot com
- Date: Tue, 22 Jul 2014 16:41:10 +0200 (CEST)
- Subject: Reverting the s390 jmp_buf/ucontext_t ABI change
- Authentication-results: sourceware.org; auth=none
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.
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com