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: Aurelien Jarno <aurelien at aurel32 dot net>
- Cc: 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 00:42:58 -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> <20140714183123 dot GH1239 at hall dot aurel32 dot net> <20140714221933 dot GJ1239 at hall dot aurel32 dot net>
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.
> 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?
Andreas will have to comment on this particular case.
Though it looks like s390 will need more versioned interfaces
to support this transition.
The SO name bump case should be looked at with serious
consideration.
Cheers,
Carlos.