This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCHv3 00/24] ILP32 support in ARM64
- From: Rich Felker <dalias at libc dot org>
- To: Catalin Marinas <catalin dot marinas at arm dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, "arnd at arndb dot de" <arnd at arndb dot de>, "pinskia at gmail dot com" <pinskia at gmail dot com>, "musl at lists dot openwall dot com" <musl at lists dot openwall dot com>, "linux-kernel at vger dot kernel dot org" <linux-kernel at vger dot kernel dot org>, Andrew Pinski <apinski at cavium dot com>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>, "linux-arm-kernel at lists dot infradead dot org" <linux-arm-kernel at lists dot infradead dot org>
- Date: Fri, 13 Feb 2015 13:37:07 -0500
- Subject: Re: [PATCHv3 00/24] ILP32 support in ARM64
- Authentication-results: sourceware.org; auth=none
- References: <20141002155217 dot GH32147 at e104818-lin dot cambridge dot arm dot com> <20150210181302 dot GA23886 at brightrain dot aerifal dot cx> <20150211173919 dot GF9058 at e104818-lin dot cambridge dot arm dot com> <20150211192118 dot GC23507 at brightrain dot aerifal dot cx> <20150212181735 dot GF25491 at e104818-lin dot cambridge dot arm dot com> <501530245 dot 495972 dot 1423767564997 dot JavaMail dot open-xchange at oxbaltgw04 dot schlund dot de> <20150213133355 dot GD3508 at e104818-lin dot cambridge dot arm dot com> <20150213163013 dot GE23507 at brightrain dot aerifal dot cx> <20150213173345 dot GA26217 at e104818-lin dot cambridge dot arm dot com>
On Fri, Feb 13, 2015 at 05:33:46PM +0000, Catalin Marinas wrote:
> > > > The data structure definition is a little bit fragile, as it depends on
> > > > user space not using the __BIT_ENDIAN symbol in a conflicting way. So
> > > > far we have managed to keep that outside of general purpose headers, but
> > > > it should at least blow up in an obvious way if it does, rather than
> > > > breaking silently.
> > > >
> > > > I still think it's more practical to keep the zeroing in user space though.
> > > > In that case, we keep defining __kernel_timespec64 with a 'typedef long
> > > > long __kernel_snseconds_t', and it's up to the libc to either use
> > > > __kernel_timespec64 as its timespec, or to define a C11-compliant
> > > > timespec itself and zero out the bits before passing the data to the kernel.
> > >
> > > The problem with doing this in user space is syscall(2). If we don't
> > > allow it, then it's fine to do the padding in libc.
> >
> > It's already the case that callers have to tiptoe around syscall(2)
> > usage on a per-arch basis for silly things like the convention for
> > passing 64-bit arguments on 32-bit archs, different arg orders to work
> > around 64-bit alignment and issues with too many args, and various
> > legacy issues. So I think manual use of syscall(2) is a less-critical
> > issue, though of course from a libc perspective I would very much like
> > for the kernel to handle it right.
>
> I think there is another problem with sign-extending tv_nsec in libc.
> The prototype for functions like clock_settime(2) take a const struct
> timespec *. There isn't anything to prevent such structure being in a
> read-only section, even though it is unlikely. So libc would have to
> duplicate the structure rather than just sign-extending tv_nsec in
> place.
Yes, we already have to do this for x32 in musl. I'd rather not have
to do the same for aarch64-ILP32.
Rich