From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7174 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: pthread object sizes for new archs Date: Tue, 10 Mar 2015 14:24:41 -0400 Message-ID: <20150310182441.GC23507@brightrain.aerifal.cx> References: <20150310010733.GA26844@brightrain.aerifal.cx> <1425976244.2199.1.camel@inria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1426011903 4655 80.91.229.3 (10 Mar 2015 18:25:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Mar 2015 18:25:03 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7187-gllmg-musl=m.gmane.org@lists.openwall.com Tue Mar 10 19:25:02 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YVOpx-0008Lf-St for gllmg-musl@m.gmane.org; Tue, 10 Mar 2015 19:25:01 +0100 Original-Received: (qmail 15704 invoked by uid 550); 10 Mar 2015 18:24:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 15648 invoked from network); 10 Mar 2015 18:24:55 -0000 Content-Disposition: inline In-Reply-To: <1425976244.2199.1.camel@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7174 Archived-At: 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