[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 10 Mar 2015 14:24:41 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: pthread object sizes for new archs
On Tue, Mar 10, 2015 at 09:30:44AM +0100, Jens Gustedt wrote:
> Hello,
>
> 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.
Yes.
> 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?
Yes. There are no public structs containing these, and it's unlikely
there ever would be. If so they could contain their own internal
padding to match.
> - 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.
This does not work now anyway, and it's not intended to work.
- On glibc certain symbols like strerror_r map to nonstandard
functions with different signatures and the standard function has
some alternate name.
- On 32-bit archs the 32-bit-off_t functions would get used and
horribly misinterpret their argument lists.
There may be other reasons I'm not thinking of right now too.
> I hope that there is nobody out there, who would be currently using
> this model, perhaps unknowingly.
If so it's already broken, so breaking quicker and more spectacularly
would be nice. :-)
Rich
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.
