[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 9 Sep 2014 11:00:10 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: c++ abi
On Tue, Sep 09, 2014 at 01:43:52PM +0200, Szabolcs Nagy wrote:
> * Szabolcs Nagy <nsz@...t70.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
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.
