Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 10 Mar 2015 09:30:44 +0100
From: Jens Gustedt <>
Subject: Re: pthread object sizes for new archs


Am Montag, den 09.03.2015, 21:07 -0400 schrieb Rich Felker:
> How does this affect "glibc ABI compatibility"? Very little. As long
> as the sizes of the musl types are no larger than the sizes of the
> glibc types on the same arch, compatibility with glibc binary code
> (apps or libs) is not affected. All that is affected if the ABI of
> third-party libraries that use pthread types as members of public
> structs, and it only matters if you're calling such libraries using
> the glibc-derived ABI from code compiled against musl and using the
> affected structures. This is a very unusual usage case, not something
> we've ever prioritized supporting (it's broken in several other ways
> anyway, or at least it was historically), and IMO it's not worth
> severely bloating new archs that people actually want to use.

So to rephrase your arguments for that

 - For the case I compile my code with the glibc ABI and link it with
   musl: any struct that has pthread (or C11 thread) components in it
   will potentially only use a smaller part of that pthread (C11)
   component. In particular in that case when compiling with the glibc
   ABI the compiler always generates a consistent offset for the
   pthread components. Sounds ok.

   But this only works because the glibc ABI doesn't export any
   interface that has a visible combination of different pthread
   components. Are we sure about that?

 - For the case that I compile code with the musl ABI and link it with
   glibc, this may (and probably will) cause out-of-bounds errors on
   execution. I would very much prefer that big warnings are already
   issued when doing such a link, or even better if such a link would
   fail systematically.

   I hope that there is nobody out there, who would be currently using
   this model, perhaps unknowingly.


:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: ::

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.