This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v8 3/3] y2038: linux: Provide __clock_settime64 implementation

Hi Joseph,

> On Wed, 18 Sep 2019, Lukasz Majewski wrote:
> > Tests:
> > - The code has been tested with x86_64/x86 (native compilation):
> > make PARALLELMFLAGS="-j8" && make xcheck PARALLELMFLAGS="-j8"
> > 
> > - Run specific tests on ARM/x86 32bit systems (qemu):
> >
> > and run tests:
> >
> > on kernels with and without 64 bit time support.  
> Could you give more details of the configurations (including kernel 
> headers version, --enable-kernel version, kernel version used at
> runtime) for which you have built glibc and run the full glibc
> testsuite?  I suspect this code is pretty close to being ready to go
> in - but such patches have plenty of scope for mistakes (such as were
> in earlier RV32 patch versions) such as typos, transposed parameters,
> etc., that are hard for humans to spot reliably and easy for
> compilers and testsuites to spot, so it's important to know that
> sufficient automated tests have been run to catch any such mistakes.

So I tested this on ARM32 QEMU BSP build with meta-y2038 [1].

I. Build testing:
- Machine's

- Using glib's

for qemu ARM.

- ../src/scripts/

II. Runtime testing - with BSP [1]:
runqemu -d y2038arm nographic

- PREFERRED_VERSION_linux-y2038 = "5.1%" &&

  Linux y2038arm 5.1.21-y2038-4a9b1eb8bc3ba4ad8b3b1aa3317cf8d4a3aaad83

  (Support __ASSUME_TIME64_SYSCALLS defined)

- Only PREFERRED_VERSION_linux-y2038 = "5.1%" - the minimal kernel
  version is default one for current mainline glibc

  (The __ASSUME_TIME64_SYSCALLS not defined, but kernel supports
  __clock_settime64 syscalls).

- PREFERRED_VERSION_linux-lts = "4.19%"
  with default minimal kernel version for contemporary glibc
  (SHA1: 87accae3978c77c1a50d19ea8e3da3f0248d2612)

  This kernel doesn't support __clock_settime64 syscalls, so we
  fallback to clock_settime.

Above tests are performed with Y2038 redirection applied [2] as well as
without (so the __TIMESIZE != 64 execution path is checked as well).

III. Syscalls unit tests - test_y2038 program [3] installed on BSP.

IV. For x86_64 I do run the - as I can do it on my HOST PC

make PARALLELMFLAGS="-j8" && make xcheck PARALLELMFLAGS="-j8"

(before and after the patchset).

> I gave a list in 
> <> of five 
> configurations I think are relevant to cover the different cases in 
> patches such as this ("new" = 5.1 or later; Florian's changes to
> provide syscall tables in glibc would allow "#ifdef
> __NR_clock_settime64" to be removed and eliminate case (b)):
> (a) one that has always had 64-bit time, e.g. x86_64;

Point IV.

> (b) one with 32-bit time and old kernel headers (any kernel version
> at runtime);

Point II.

> (c) one with 32-bit time and new kernel headers, old kernel at
> runtime;
> (d) one with 32-bit time and new kernel headers, new kernel at
> runtime but no --enable-kernel;
> (e) one with 32-bit time and new kernel at runtime and new 
> --enable-kernel.

Point II.


I will double check if the above points are in sync with points a) to

> If some of these are problematic to test, you can ask for help
> testing them.  For *this particular* patch you might not need to test
> both (c) and (d), because they are identical as far as compilation is
> concerned and the testsuite doesn't really cover execution of
> clock_settime anyway.  But it's in the nature of the Y2038 changes -
> involving lots of conditional code - that it's necessary to test in
> several different configurations to cover the conditionals adequately.

QEMU (and OE/Yocto) helps here ...

> (For avoidance of doubt, it is *not* necessary to run
> for this patch, and nor would running
> be sufficient since it doesn't do execution
> testing or cover the kernel headers version and --enable-kernel
> variants.)

The build-many-glibcs helps with checking if there aren't some odd
build breaks. It is one of many test approaches for testing the Y2038


[1] -
[2] -
[3] -

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:

Attachment: pgp0DW50GjvoN.pgp
Description: OpenPGP digital signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]