From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: c++ abi
Date: Tue, 9 Sep 2014 11:00:10 -0400 [thread overview]
Message-ID: <20140909150010.GI23797@brightrain.aerifal.cx> (raw)
In-Reply-To: <20140909114352.GK10361@port70.net>
On Tue, Sep 09, 2014 at 01:43:52PM +0200, Szabolcs Nagy wrote:
> * Szabolcs Nagy <nsz@port70.net> [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
prev parent reply other threads:[~2014-09-09 15:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-09 1:04 Szabolcs Nagy
2014-09-09 11:43 ` Szabolcs Nagy
2014-09-09 15:00 ` Rich Felker [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140909150010.GI23797@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).