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

[Stafford Horne <shorne@gmail.com>]

On Wed, Oct 13, 2021 at 08:47:39PM +0000, Joseph Myers wrote:
> 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.

OK, thank's for the clarification I missed that part of the documentation.

But that explains all of the build failures.

> > > +@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.

OK, this makes sense now.  Its a bit confusing saying _TIME_BITS=64, because
_TIME_BITS does not have to be defined at all.  Let me read the docs again maybe
there is a patch in there to help clarify for the next reader too.

> > 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.

I see, thats a much more clear explaination.

> 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.

OK, makes sense.

Thanks for clarifying, I am still having the issue with struct timex using
__USE_TIME_BITS64 and choosing a 32-bit implementation.

I think I can go over all of the code again and add some clarifications via
comments and doc's, then I will probably understand enough to know the right
approach to fix the timex issue.

Just for reference/brain dump, sysdeps/unix/sysv/linux/bits/timex.h defines:

    struct timex {
    # ifdef __USE_TIME_BITS64
    ...
       long long offset;
    ...
    # else
    ...
       __syscall_slong_t offset;
    ...
    # endif

For the above on openrisc I need offset (and other fields) to be 64-bit.

But there are 2 problems:
  1. __syscall_slong_t is 32-bit
  2. __USE_TIME_BITS64 is not defined for openrisc (as per above)

So options:
  1. Use a different type other __syscall_slong_t, i.e. time_t
  2. Use a different macro other than __USE_TIME_BITS64

Timex is defined 3 times:
  - 2 times          (external) sysdeps/unix/sysv/linux/bits/timex.h
  - 1 time __timex64 (internal) sysdeps/unix/sysv/linux/include/sys/timex.h

-Stafford