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: Aurelien Jarno <aurelien at aurel32 dot net>
- To: Carlos O'Donell <carlos at redhat dot com>
- 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 07:18:06 +0200
- 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> <53C4B152 dot 7090606 at redhat dot com>
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.
> > 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.
Cheers,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net