This is the mail archive of the
mailing list for the glibc project.
Re: [PATCHv3 00/24] ILP32 support in ARM64
- From: Rich Felker <dalias at libc dot org>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Catalin Marinas <catalin dot marinas at arm dot com>, Andrew Pinski <apinski at cavium dot com>, "linux-arm-kernel at lists dot infradead dot org" <linux-arm-kernel at lists dot infradead dot org>, LKML <linux-kernel at vger dot kernel dot org>, Andrew Pinski <pinskia at gmail dot com>, musl at lists dot openwall dot com, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 11 Feb 2015 14:47:41 -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> <CAMe9rOqX-VpjZ+E-JCusk+e4Kpw1V1tsFq1Kjtai5DR9saKLaA at mail dot gmail dot com> <20150211190252 dot GB23507 at brightrain dot aerifal dot cx> <CAMe9rOoME1fct=Dk1YFeoJbayvhdsaCUBZCY2YD6jK58J7=MkA at mail dot gmail dot com> <20150211192558 dot GE23507 at brightrain dot aerifal dot cx> <CAMe9rOpr6j1siK5gJ_HPLTOfjG_sLOL48TFzaLx+shCS9O8ahA at mail dot gmail dot com>
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 <email@example.com> 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
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.