This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Distributions still suffering from s390 ABI change problems.
- From: Rich Felker <dalias at libc dot org>
- To: Andreas Arnez <arnez at linux dot vnet dot ibm dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, David Miller <davem at davemloft dot net>, aurelien at aurel32 dot net, Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>, siddhesh at redhat dot com, allan at archlinux dot org, libc-alpha at sourceware dot org
- Date: Tue, 15 Jul 2014 12:43:07 -0400
- Subject: Re: Distributions still suffering from s390 ABI change problems.
- Authentication-results: sourceware.org; auth=none
- References: <20140713182420 dot GA14513 at hall dot aurel32 dot net> <20140714052022 dot GR609 at spoyarek dot pnq dot redhat dot com> <20140714072228 dot GF1239 at hall dot aurel32 dot net> <20140714 dot 002520 dot 985400136122770421 dot davem at davemloft dot net> <53C40A5A dot 5050202 at redhat dot com> <20140715050009 dot GU179 at brightrain dot aerifal dot cx> <878unuegdh dot fsf at br87z6lw dot de dot ibm dot com>
On Tue, Jul 15, 2014 at 06:28:10PM +0200, Andreas Arnez wrote:
> On Tue, Jul 15 2014, Rich Felker wrote:
>
> > On Mon, Jul 14, 2014 at 12:50:34PM -0400, Carlos O'Donell wrote:
> >> On 07/14/2014 03:25 AM, David Miller wrote:
> >> > From: Aurelien Jarno <aurelien@aurel32.net>
> >> > Date: Mon, 14 Jul 2014 09:22:28 +0200
> >> >
> >> >> We can continue handling this ABI change by rebuilding all packages
> >> >> dependind on libpng, but I am afraid that embedding a jmp_buf in a
> >> >> structure is not that uncommon and that we are going to discover
> >> >> more affected packages.
> >> >
> >> > This is a really serious mess.
> >>
> >> There was no other way around this, and our tooling sucks for detecting
> >> mixed ABI usage and telling users how to fix it.
> >
> > Yes there was. No matter how much state setjmp needs to store, there
> > is always a way to avoid ABI breakage as long as jmp_buf is at least
> > the size of a pointer:
> >
> > #define setjmp(jb) __new_setjmp(jb, alloca(__get_real_jb_size()))
> >
> > Then the jmp_buf need only store a pointer to the caller-provided
> > register-storage space.
> >
> > This design is fully immune to any need for ABI change when expanding
> > the size of the state setjmp has to preserve.
>
> Good idea, but I'm afraid it doesn't really work out. Consider a code
> snippet like this:
>
> jmp_buf my_jmp_buf;
>
> int do_some_work_forever (void)
> {
> while (1)
> {
> if (setjmp (my_jmp_buf) != 0)
> indicate_error ();
>
> do_some_work ();
> }
> }
>
> Here, setjmp() is called in an endless loop. If alloca() was involved
> in its implementation, we'd overflow the stack at some point.
Sorry. I wanted to use a compound literal, which would avoid this
problem, but IIRC VLA is not allowed there. Instead you can just use a
GCC statement-expression, though.
Rich