From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6130 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: c++ abi Date: Tue, 9 Sep 2014 11:00:10 -0400 Message-ID: <20140909150010.GI23797@brightrain.aerifal.cx> References: <20140909010406.GJ10361@port70.net> <20140909114352.GK10361@port70.net> 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 1410274836 13084 80.91.229.3 (9 Sep 2014 15:00:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Sep 2014 15:00:36 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6143-gllmg-musl=m.gmane.org@lists.openwall.com Tue Sep 09 17:00:29 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XRMu8-0000ZJ-0R for gllmg-musl@plane.gmane.org; Tue, 09 Sep 2014 17:00:24 +0200 Original-Received: (qmail 21802 invoked by uid 550); 9 Sep 2014 15:00:23 -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 21794 invoked from network); 9 Sep 2014 15:00:23 -0000 Content-Disposition: inline In-Reply-To: <20140909114352.GK10361@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6130 Archived-At: On Tue, Sep 09, 2014 at 01:43:52PM +0200, Szabolcs Nagy wrote: > * Szabolcs Nagy [2014-09-09 03:04:06 +0200]: > > --- x86_64.glibc.abi 2014-09-09 01:40:22.210277471 +0200 > > +++ x86_64.musl.abi 2014-09-09 01:41:04.618487657 +0200 > .... > > @@ -162 +162 @@ > > -x_sched_param(sched_param, size (*) [4], align (*) [4]) > > +x_sched_param(sched_param, size (*) [48], align (*) [8]) > .... > > @@ -267 +267 @@ > > -x_pthread_rwlockattr_t(pthread_rwlockattr_t, size (*) [8], align (*) [8]) > > +x_pthread_rwlockattr_t(pthread_rwlockattr_t, size (*) [8], align (*) [4]) > .... > > @@ -317 +317 @@ > > -x_sem_t(sem_t, size (*) [32], align (*) [8]) > > +x_sem_t(sem_t, size (*) [32], align (*) [4]) These alignment differences were unfortunate, but I think it would do more harm than good trying to change now. They only affect ABI between two TUs build against different libc headers that are using the above types as part of the API between themselves. They do not affect the ABI to libc; musl is happy to take glibc's over-aligned types. > .... > > @@ -360,2 +360,2 @@ > > -x_quad_t(long, size (*) [8], align (*) [8]) > > -x_rlim_t(unsigned long, size (*) [8], align (*) [8]) > > +x_quad_t(long long, size (*) [8], align (*) [8]) > > +x_rlim_t(unsigned long long, size (*) [8], align (*) [8]) quad_t is a nonstandard legacy type that never should have been used to begin with, and I doubt it comes up in C++ at all. I'm indifferent on fixing it. rlim_t is probably unlikely to be used as an argument type in C++, but I'd rather not break stuff using it. > > @@ -363 +363 @@ > > -x_rusage(rusage, size (*) [144], align (*) [8]) > > +x_rusage(rusage, size (*) [272], align (*) [8]) > > @@ -381,2 +381,2 @@ > > -x_cmsghdr(cmsghdr, size (*) [16], align (*) [8]) > > -x_fd_mask(long, size (*) [8], align (*) [8]) > > +x_cmsghdr(cmsghdr, size (*) [16], align (*) [4]) > > +x_fd_mask(unsigned long, size (*) [8], align (*) [8]) > > cant the different size/alignment cause abi issues > when these types are used embedded into a struct? For cmsghdr, I don't think you would use it in a struct; it's normally used as a string of multiple headers in an allocated buffer where a pointer to the buffer is in the msghdr struct. But it might be nice if we could fix this. It's even _possible_ that the missing alignment is causing the macros that advance this struct to mismatch the kernel ABI in some cases; this should be checked. If that's determined not to be a problem, it's probably safest just to leave it. Rich