[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150211194741.GI23507@brightrain.aerifal.cx>
Date: Wed, 11 Feb 2015 14:47:41 -0500
From: Rich Felker <dalias@...c.org>
To: "H.J. Lu" <hjl.tools@...il.com>
Cc: Catalin Marinas <catalin.marinas@....com>,
Andrew Pinski <apinski@...ium.com>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Pinski <pinskia@...il.com>, musl@...ts.openwall.com,
GNU C Library <libc-alpha@...rceware.org>
Subject: Re: [PATCHv3 00/24] ILP32 support in ARM64
On Wed, Feb 11, 2015 at 11:34:23AM -0800, H.J. Lu wrote:
> On Wed, Feb 11, 2015 at 11:25 AM, Rich Felker <dalias@...c.org> wrote:
> > On Wed, Feb 11, 2015 at 11:16:58AM -0800, H.J. Lu wrote:
> >> >> > 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.
> >> >
> >> > From the glibc side, I thought things went by a consensus process
> >> > these days, not the old WONTFIX regime of he who shall not be named.
> >> > If this is not fixed for x32, then x32 cannot provide a conforming C
> >> > environment and thus it's rather a toy target. But I think we should
> >> > discuss this on libc-alpha. In the mean time please leave it REOPENED.
> >>
> >> As I said in PR, the issue has been raised in Mar, 2012 when the
> >> x32 port was submitted. It has been decided that x32 won't conform
> >> to tv_nsec, blksize_t, and suseconds_t as long. I don't believe we
> >> will change them to conform to POSIX.
> >
> > I briefly reviewed that discussion and I think the decision made was
> > about an obscure POSIX requirement about supporting at least one
> > compilation environment where certain types have rank <= long. This is
>
> The example you gave in PR is similar to
>
> https://sourceware.org/ml/libc-alpha/2012-03/msg00456.html
Yes, but after that the conversation seemed to get derailed into the
blksize_t etc. stuff about "compilation environments" that's largely
irrelevant. I think this prevented the core tv_nsec issue from getting
discussed further, unless I'm missing part of that thread.
> > trivially satisfied if you consider x32 and x86_64 separate
> > compilation environments, but it's not related to the core issue: that
> > the definition of timespec violates core (not obscure) requirements of
> > both POSIX and C11. At the time you were probably unaware of the C11
> > requirement. Note that it's a LOT harder to effect change in the C
> > standard, so even if the Austin Group would be amenable to changing
> > the requirement for timespec to allow something like nseconds_t,
> > getting WG14 to make this change to work around a Linux/glibc mistake
> > does not sound practical.
>
> That is very unfortunate. I consider it is too late for x32 to change.
Why? It's hardly an incompatible ABI change, as long as the
kernel/libc fills the upper bits (for old programs that read them
based on the old headers) when structs are read from the kernel to the
application, and ignores the upper bits (potentially set or left
uninitialized by the application) when strings are passed from
userspace to the kernel. Newly built apps using the struct definition
with 32-bit tv_nsec would need new libc to ensure that the high bits
aren't interpreted, but this could be handled by symbol versioning.
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.
