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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- 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:45:25 -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>
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?
Cheers,
Carlos.