This is the mail archive of the
mailing list for the glibc project.
Re: [PATCHv3 00/24] ILP32 support in ARM64
- From: Andy Lutomirski <luto at amacapital dot net>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>, Rich Felker <dalias at libc dot org>
- 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 12:15:56 -0800
- 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> <20150211194741 dot GI23507 at brightrain dot aerifal dot cx> <CAMe9rOrVGFcQN3J1-pkXWd9j4MaQv2QxPrA5cTtLPBPaQ2-zfw at mail dot gmail dot com>
On 02/11/2015 11:57 AM, H.J. Lu wrote:
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.
We have considered this option. But since kernel wouldn't change
tv_nsec/tv_usec handling just for x32, it wasn't selected.
Did anyone *ask* the kernel people (e.g. hpa)?