This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fifth draft of the Y2038 design document
On Wed, 22 Feb 2017, Albert ARIBAUD wrote:
> Hi Joseph,
>
> On Wed, 22 Feb 2017 20:55:39 +0000, Joseph Myers
> <joseph@codesourcery.com> wrote :
>
> > On Wed, 22 Feb 2017, Albert ARIBAUD wrote:
> >
> > > - this leaves the case of a 64-bit architecture kernel providing a
> > > 32-bit ABI to 32-bit code. I am not planning on supporting such a
> > > scenario.
> >
> > There are several such ABIs (ILP32 ABI for a 64-bit architecture) already
> > supported in glibc, e.g. MIPS n32, and all of them that don't already have
> > support for 64-bit time_t will need to have it added.
>
> I /was/ not planning on supporting such a scenario. :)
>
> More seriously: is there already a list of these ABIs?
I'm not convinced that is a meaningful question. You can identify ABIs
with 32-bit time_t by e.g. building for different ABIs with
build-many-glibcs.py then compiling a test program with each compiler and
corresponding options. Some such ABIs may require a 64-bit kernel. Some
may work with both 32-bit and 64-bit kernels (e.g. 32-bit x86). Some may
be for 32-bit-only architectures.
In all cases, whether the kernel is working with a 32-bit or 64-bit
address space is not relevant; you work with the syscall ABI as it is,
plus whatever additions are made to it in the course of the Y2038 work.
That said, I think the following ABIs use 64-bit register size in
userspace while being ILP32 ABIs. You'll need to examine the code more
closely in each case to determine what size time_t is, and to what extent
if any 64-bit registers are involved in the syscall ABI. There may be
other cases where 64-bit registers can in fact be used for what's normally
considered a 32-bit ABI (e.g. people have done some work on being able to
use 64-bit registers for 32-bit powerpc code, although the registers are
32-bit for all purposes in the function-calling ABI).
AArch64 ILP32 (not yet in glibc)
MIPS n32
TileGX32
x86_64 x32
--
Joseph S. Myers
joseph@codesourcery.com