Re: Re: [PATCHv3 00/24] ILP32 support in ARM64

[Josiah Worcester <josiahw@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2836 bytes --]

On Feb 11, 2015 12:59 PM, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>
> On Tue, Feb 10, 2015 at 10:13 AM, Rich Felker <dalias@libc.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."?

[-- Attachment #2: Type: text/html, Size: 3913 bytes --]