Re: Distributions still suffering from s390 ABI change problems.

["Carlos O'Donell" <carlos at redhat dot com>]

On 07/15/2014 01:18 AM, Aurelien Jarno wrote:
> On Tue, Jul 15, 2014 at 12:42:58AM -0400, Carlos O'Donell wrote:
>> On 07/14/2014 06:19 PM, Aurelien Jarno wrote:
>>> On Mon, Jul 14, 2014 at 08:31:23PM +0200, Aurelien Jarno wrote:
>>>> Also there seems to be a problem in the compatibility symbols, some code
>>>> fully compiled against libc 2.18 do not run with libc 2.19, but do run
>>>> with libc 2.19 and the change reverted. I *suspect*, but nothing is
>>>> confirmed yet, that the compatibility symbols to not handle all cases
>>>> of the pthread_cleanup functions.
>>>
>>> The problem is that jmp_buf is "internally" used in the
>>> __pthread_unwind_buf_t structure, so its size is changed.
>>
>> That doesn't in and of itself cause a problem. It's only when
>> that is exposed externally that it's an issue.
> 
> This structure is part of pthread.h so it might also be used externally
> and embedded into a structure, just like the jump_buf one.

That is not a supported use since the symbol is in the implementations
name space e.g. __. Therefore this is not a real problem.

>>> To fix that functions taking this struct as argument should be
>>> versioned. That said pthread.h being part of the public API, some code
>>> might embed __pthread_unwind_buf_t in another structure. At least that
>>> that will permit old programs not depending on any new library to 
>>> continue working. At a first glance, the following functions are
>>> affected:
>>> - __pthread_register_cancel
>>> - __pthread_unregister_cancel
>>> - __pthread_register_cancel_defer
>>> - __pthread_unregister_cancel_restore
>>> - __pthread_unwind
>>> - __pthread_unwind_next
>>
>> These again aren't problems directly.
>>
>> The problem is that pthread_cleanup_push and pthread_cleanup_pop,
>> to name two functions, are implemented as macros that embed the
>> size of the __pthread_unwind_buf_t into the calling program.
>>
>> It would seem to me that you are correct in that all programs that
>> call:
>> * pthread_cleanup_push
>> * pthread_cleanup_pop
>> * pthread_cleanup_push_defer_np
>> * pthread_cleanup_pop_restore_np
>>
>> Will contain a too-small __pthread_unwind_buf_t structure which
>> will get interpreted internally as a pthread_unwind_buf of the
>> newer ABI size and that will cause reads from beyond the size
>> of the structure which is undefined behaviour.
>>
>> Did I get that right?
> 
> Yes, it's correct. In addition to reads beyond the size, it seems that
> some data end-up being corrupted, and the longjmp is done at the wrong
> address. I haven't fully understood the whole process yet.
> 
> This is the reason why gauche and mono break by just using the new libc
> and without rebuilding anything else.

OK, we need more versioning here, but it won't solve the mixed-ABI
uses that happen in debian as you rebuild some but not all of the
plugins for say perl.

I don't think that bumping the glibc SO name would help either since
it's not possible to load libc.so twice given the implementation.
I'm pretty sure this breaks TLS usage in the second loaded glibc.
I just tried bumping the SO name for x86-64 to test this and it's
crashing at startup when an application needs both libcs.

If you can only have libc.so.6 or libc.so.7 loaded, then you
you don't support mixed-ABI. We could avoid mixed-ABI using a
runtime check instead of a SONAME bump...

Cheers,
Carlos.