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: Carlos O'Donell <carlos at redhat dot com>
- Cc: Aurelien Jarno <aurelien at aurel32 dot net>, David Miller <davem at davemloft 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:48:09 -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> <20140715103532 dot GB14513 at hall dot aurel32 dot net> <53C54C92 dot 1000207 at redhat dot com> <20140715164145 dot GC17402 at brightrain dot aerifal dot cx> <53C55AA5 dot 5020402 at redhat dot com>
On Tue, Jul 15, 2014 at 12:45:25PM -0400, Carlos O'Donell wrote:
> On 07/15/2014 12:41 PM, Rich Felker wrote:
> > On Tue, Jul 15, 2014 at 11:45:22AM -0400, Carlos O'Donell wrote:
> >> On 07/15/2014 06:35 AM, Aurelien Jarno wrote:
> >>> On Tue, Jul 15, 2014 at 01:00:09AM -0400, 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 would work if jmp_buf was an opaque structure. It is not the case
> >>> and we can imagine code accessing its content. In that case it will
> >>> still break.
> >>
> >> Conservative gc's like ruby access it and this would break ruby like
> >> it did on ARM when we encrypted more of the jmp_buf than intended.
> >
> > Wouldn't it just follow the pointer? Even if it didn't, the pointers
> > that used to be inside the jmp_buf would now be on the stack, which
> > the GC will find anyway.
>
> It might, but what I remember from the code it used the jmp_buf as
> the starting point. I would have to review the code again to see if
> it fell back to a straight stack walk after the jmp_buf.
>
> If the jmp_buf wasn't on the stack then you still have a problem?
I don't think so. All of the pointers from saved registers end up
saved on the stack rather than being in the jmp_buf, which makes it
very clear to the GC that they're live. Having them just inside the
jmp_buf is the hard case, since the GC has to specially know to look
there. When they're on the stack, it's just like normal saving by the
callee on the stack.
Rich