Date: Wed, 11 Feb 2015 13:04:19 -0600 From: Josiah Worcester <josiahw@...il.com> To: musl@...ts.openwall.com Cc: GNU C Library <libc-alpha@...rceware.org>, Andrew Pinski <pinskia@...il.com>, Rich Felker <dalias@...c.org>, linux-arm-kernel@...ts.infradead.org, LKML <linux-kernel@...r.kernel.org>, Andrew Pinski <apinski@...ium.com>, Catalin Marinas <catalin.marinas@....com> Subject: Re: Re: [PATCHv3 00/24] ILP32 support in ARM64 On Feb 11, 2015 12:59 PM, "H.J. Lu" <hjl.tools@...il.com> wrote: > > On Tue, Feb 10, 2015 at 10:13 AM, Rich Felker <dalias@...c.org> wrote: > > On Thu, 2 Oct 2014 at 16:52:18 +0100, Catalin Marinas wrote: > >> On Wed, Sep 03, 2014 at 10:18:54PM +0100, Andrew Pinski wrote: > >> > New version with all of the requested changes. Updated to the > >> > latest sources. > >> > > >> > Notable changes from the previous versions: > >> > VDSO code has been factored out to be easier to understand and > >> > easier to maintain. > >> > Move the config option to the last thing that gets added. > >> > Added some extra COMPAT_* macros for core dumping for easier usage. > >> > >> Apart from a few comments I've made, I would also like to see non-empty > >> commit logs and long line wrapping (both in commit logs and > >> Documentation/). Otherwise, the patches look fine. > >> > >> So what are the next steps? Are the glibc folk ok with the ILP32 Linux > >> ABI? On the kernel side, what I would like to see: > > > > I don't know if this has been discussed on libc-alpha yet or not, but > > I think we need to open a discussion of how it relates to open glibc > > bug #16437, which presently applies only to x32 (ILP32 ABI on x86_64): > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=16437 > > Please leave x32 out of this discussion. I have resolved this bug > as WONTFIX. > > > While most of the other type changes proposed (I'm looking at > > https://lkml.org/lkml/2014/9/3/719) are permissible and simply > > ugly/undesirable, defining struct timespec with tv_nsec having any > > type other than long conflicts with the requirements of C11 and POSIX, > > and WG14 is unlikely to be interested in changing the C language > > because the Linux kernel has the wrong type in timespec. > > > > Note that on aarch64 ILP32, the consequences of not fixing this right > > away will be much worse than on x32, since aarch64 (at least as I > > understand it) supports big endian where it's not just a matter of > > sign-extending the value from userspace and ignoring the padding, but > > rather changing the offset of the tv_nsec member. > > > > Working around the discrepencies in userspace IS possible, but ugly. > > We do it in musl libc for x32 right now -- see: > > > > http://git.musl-libc.org/cgit/musl/tree/arch/x32/syscall_arch.h?id=v1.1.6 > > http://git.musl-libc.org/cgit/musl/tree/arch/x32/src/syscall_cp_fixup.c?id=v1.1.6 > > You are free to do what you feel appropriate. I have no plans > to change x32 on this in glibc at this moment. Would you be so kind as to document your intentional nonconformance with C and POSIX in the glibc manual, perhaps also the readme and website? Something like "for the sake of simplicity, some ports do not provide a correct C environment. Any such failures should not be considered bugs."? Content of type "text/html" skipped
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.