Re: [Y2038] Question about porting y2038-tests to glibc

[Lukasz Majewski <lukma@denx.de>]

[-- Attachment #1: Type: text/plain, Size: 5739 bytes --]

Hi Joseph,

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

Ok, so QEMU run of tests seems to be an option - especially the "user
mode" https://yurovsky.github.io/2016/12/14/qemu-user-mode.html

seems appealing as we do have cross compiled glibc available anyway. It
looks like we can get the $? of cross compiled program execution as
well.

However, according to:
https://www.qemu.org/docs/master/user/main.html QEMU does the syscalls
translation between target and host - this may be not the same as we
have with normally running kernel.

(But on the other hand - ARM 64 bit time supporting syscalls were added
in 5.1 kernel - now we do have 5.9, so those syscalls shall be
supported already in QEMU).

After running build-many-glibcs.py we do have cross-compiled glibc
(which includes tests).

Then we would just need to run qemu-{arm|mips|ppc} with y2038 tests and
read the status.

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

Yes, the faketime uses LD_PRELOAD to redirect eligible syscalls to
libfaketime.

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

Then IMHO it would be more feasible to just use qemu in the user mode
as outlined above.

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

I think that they are necessary, as most errors are visible after some
changes in external/internal structures. With setting/reading time after
Y2038 we can check this. Also we can check error paths when used
kernel mismatch glibc with time_t size.

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

Unfortunately, it seems like the CLOCK_REALTIME will not be supported
soon.

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

Agree.

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

Could you elaborate on this idea? Is there any test in glibc which only
checks if function can be compiled and linked? Wouldn't this be too
little to prevent regression?

Most code, which provides 64 bit time support, uses syscalls supporting
64 bit time, which were added to Linux 5.1. It looks natural for me
that we test this by reading / writing time by those syscalls. 

Overflow errors are apparent when we read time after Y2038 32 bit
time_t overflow.

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

Yes - I do agree. Unfortunately, those represent just a small subset of
the test covered code (as documented here:
https://github.com/lmajewski/y2038-tests/commits/master).

> In such cases, it
> may be useful to add tests to make sure such times are covered in the
> testsuite.  

Ok.

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

Thanks for sharing the above info. I will use it as a template where
possible.


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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]