Distributions still suffering from s390 ABI change problems.

[Carlos O'Donell]

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.

Cheers,
Carlos.