Date: Fri, 13 Feb 2015 13:37:07 -0500 From: Rich Felker <dalias@...c.org> To: Catalin Marinas <catalin.marinas@....com> Cc: "libc-alpha@...rceware.org" <libc-alpha@...rceware.org>, "arnd@...db.de" <arnd@...db.de>, "pinskia@...il.com" <pinskia@...il.com>, "musl@...ts.openwall.com" <musl@...ts.openwall.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Andrew Pinski <apinski@...ium.com>, Marcus Shawcroft <Marcus.Shawcroft@....com>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org> Subject: Re: [PATCHv3 00/24] ILP32 support in ARM64 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
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.