Re: [PATCH v3 18/24] y2038: Add support for 64-bit time on legacy ABIs

[Joseph Myers <joseph@codesourcery.com>]

On Wed, 13 Oct 2021, Stafford Horne via Libc-alpha wrote:

> Now, I am trying to build with
> CFLAGS="-g -Og -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64",
> but this is causing build failures.

glibc can't be built with those options.  All the setup for building 
functions with the correct names and aliases assumes that those macros are 
not defined when building glibc itself; defining them will cause function 
redirections that are only appropriate for user applications, not for 
building glibc itself.

> > +@item
> > +@code{_TIME_BITS=64} and port from the outset uses 64-bit
> > +@code{time_t} and word size equals to @w{32 bits} (e.g. ARC, RV32)
> > +- no action
> 
> OpenRISC falls into this category.  We have 64-bit support but word size is
> 32 bits.
> 
> What does "no action" mean here? Does it mean as long as I set _TIME_BITS=64
> no extra porting effort is needed?

"no action" means _TIME_BITS does nothing and the user gets 64-bit time 
regardless.

As with any port, the architecture-specific files need to be set up 
appropriately for the choices made by the port, and new ports may 
sometimes encounter issues in architecture-independent files for ports not 
needing various kinds of compatibility.

> Is this correct? We only use __USE_TIME_BITS64 on machines where
> __TIMESIZE==32?

The purpose of __USE_TIME_BITS64 is to enable header redirections to 
different function names on systems that support both 32-bit and 64-bit 
time_t.

For an architecture that only supports 64-bit time_t, no such redirections 
should ever be in effect and no separate function names for 64-bit time_t 
should exist, so __USE_TIME_BITS64 should not be defined.  OpenRISC should 
be just like x86_64 in this regard.

-- 
Joseph S. Myers
joseph@codesourcery.com