This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Distributions still suffering from s390 ABI change problems.


On 15/07/14 06:00, 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.
> 
> Rich
> 

You'd still need to recompile all callers of setjmp, since you can't do
the alloca call within the scope of setjmp itself.

R.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]