[Y2038] Replacement of struct timespec with struct __timespec64 in glibc internal code

[Lukasz Majewski]

Hi Joseph,

> On Wed, 3 Jun 2020, Lukasz Majewski wrote:
> 
> > To do it I could:
> > - Replace its occurences in relevant directories - like ./nptl or
> >   ./sysdeps/pthread - i.e. rename all occurrences in a single
> > directory 
> > - Replace them in functions (tests) and use explicit conversion
> >   functions - like valid_timespec_to_timespec64() before passing
> > struct __timespec64 arguments (like ones for futex_time64 for nptl).
> > 
> > - Replace _all_ occurrences in glibc tree of struct timespec with
> > struct __timespec64 at once with using sed on the glibc tree.  
> 
> Using sed obviously won't work, since external interfaces need
> different handling from purely internal uses.  I think you need to
> change things bit by bit, in sufficiently small patches for
> convenient review.
> 
> Regarding tests, I expect many tests of time-related interfaces
> should end up being built and run twice on systems that currently use
> 32-bit time, once to test the interfaces with 32-bit time and once to
> test the interfaces with 64-bit time.  

Does it mean that I shall NOT make the struct timespec to struct
__timespec64 conversion in glibc tests (e.g.
./sysdeps/pthread/tst-mutex5.c). Would those tests build infrastructure
be changed to build them w/ _TIME_BITS=64 support?


One thing puzzles me though - it seems like xclock_gettime, xclock_now,
timespec_add, timespec_sub are used by glibc tests (#include
<support/timespec.h>).

Am I correct that those functions are not exported and used solely
inside glibc?

The problem is that I do need to convert them to support 64 bit time as
pthreads use them (sysdeps/pthread/timer_settime.c). This also means
that I would need to update tests (otherwise I would experience
build/tests errors), which you don't recommend before the _TIME_BITS=64
support is added.

How to proceed in this case? Two big parts of Y2038 support are still
missing:

- One is stat and friends (which may be simplified when we move forward
  with minimal kernel version supported)

- And second are pthreads (nptl).

Pthreads are important for user space applications - so they shall be
converted sooner than latter IMHO.

> Also, tests can't generally
> use 64-bit time interfaces from libc until _TIME_BITS=64 support is
> actually implemented. 

Does it mean that tests - like sysdeps/pthread/tst-mutex5.c - will
always use exported struct timespec? (aliased to 64 bit struct 
__timespec64 when needed)?

> So I think tests would be one of the last
> places to change (and similarly installed executables). 

> Whereas any
> internal use of time in a function in the libraries that does not
> involve time in its interface can be updated more or less
> independently of any other such use, provided the relevant internal
> interfaces using 64-bit time are now available.
> 

As I stated above - e.g. timespec_sub() helper function (from /support)
is used by both pthreats and tests.

Despite it is internal function - shall I follow the pattern and
rewrite it as:

__timespec_add64(... struct __timespec64)
{

..

}
#if __TIMESIZE != 64
libc_hidden_def (__timespec_add64)

__timespec_add(... struct timespec64)
{
	call __timespec_add64();

}

However, the above approach seems to me like an overkill to do this for
internally used support function.



Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20200624/265ef252/attachment.sig>