[Y2038] Question about porting y2038-tests to glibc

[Joseph Myers]

On Wed, 28 Oct 2020, Lukasz Majewski wrote:

> Hence the question - it would be best to tie Y2038 test with all
> eligible 32 bit systems (arm, ppc32, mips, riscv32, etc) and run them
> when glibc-build-many.py is executed (as part of its check stage).

build-many-glibcs.py, by design, only does compilation tests, not 
execution tests.  It would be possible to add an option to build QEMU and 
run some execution tests under it, for those ABIs supported by QEMU, but 
it would also be a lot of work.

> 1. Use of "faketime" [3] to execute test program. This however imposes
> the requirement to have it installed (by glibc-build-many as we did with
> binutils and compilers). Good news is that there is already a python
> wrapper for it [4], so maybe the time can be set for "check" stage.

We'd need to build such an LD_PRELOAD wrapper ourselves rather than 
depending on an external package for it, and I suspect it wouldn't work 
well for glibc testing (because LD_PRELOAD can't intercept internal calls 
from a libc function to a timing function within the same library, and 
because you'd effectively end up testing the wrapper functions rather than 
the glibc functions, which misses the point of testing).

A wrapper might be more useful for testing if it intercepted syscalls 
rather than intercepting library functions at the LD_PRELOAD level, but 
that would be a lot harder to implement.

> Or maybe somebody has better idea how to solve this issue?

I think any tests requiring changing the system clock are unsuitable for 
the glibc testsuite (until the Linux kernel has time namespace support 
that includes CLOCK_REALTIME - the sort of thing people might want after 
2038 to keep running existing i386 binaries in a namespace with the clock 
set to before 2038).

However, most or all existing glibc tests for time-related interfaces 
should be run both with and without _TIME_BITS=64 (add a new variant of 
each that defines _TIME_BITS and _FILE_OFFSET_BITS to 64 before #include 
of the main test implementation).  And if some time-related interfaces are 
not currently adequately covered in the glibc testsuite, tests should be 
added for them, that are run both with and without _TIME_BITS=64.  (Tests 
of interfaces doing things requiring privileges, such as setting the 
system clock, may only verify that a call to such a function can be 
compiled and linked, not that it does anything useful at runtime.)

Some interfaces can usefully be tested with times outside the range of 
32-bit time_t, without needing to set the system clock.  For example, 
timezone-related interfaces and difftime.  In such cases, it may be useful 
to add tests to make sure such times are covered in the testsuite.  (In 
the timezone case, we have an existing tst-y2039.c, which is UNSUPPORTED 
with 32-bit time_t.  A test that does

#define _TIME_BITS 64
#define _FILE_OFFSET_BITS 64
#include "tst-y2039.c"

should be added, so that that particular bug fix gets tested in the case 
where 64-bit time is not the default but is available with _TIME_BITS=64. 
But there's probably room for more tests using explicit 64-bit times like 
that.)

-- 
Joseph S. Myers
joseph@codesourcery.com