Message ID | 20180613070019.4639-1-albert.aribaud@3adev.fr |
---|---|
Headers | show |
Series | Y2038 support batch 1 - __time64_t and __tz_convert | expand |
Added note (will be part of cover letter for all future Y2038 patch posts): All Y2038 patches are tested functionally using an ad hoc framework published at https://github.com/3adev/y2038 which runs tests using times below, at and beyond the Y2038 limit. The tests are run on ARM architecture. These patches have also been tested using build-many-glibcs.py, always for x86_64, aarch64, arm and powerpc compilers, and regularly for all compilers, and found to give the same results as those of the current glibc master above which the patches were created. On Wed, 13 Jun 2018 09:00:17 +0200, "Albert ARIBAUD (3ADEV)" <albert.aribaud@3adev.fr> wrote : > This is the first batch of Y2038 support patches. > > The first patch provides __time64_t, the 64-bit counterpart of time_t, > to be used in 64-bit-time implementations of public APIs related to time. > > The second makes __tz_convert compatible with 64-bit time. This implies > creating 64-bit-time versions of its callers and turning their original > (32-bit-time) versions into wrappers. > > Albert ARIBAUD (3ADEV) (2): > Y2038: add type __time64_t > Y2038: make __tz_convert compatible with 64-bit-time > > bits/typesizes.h | 1 + > include/time.h | 29 +++++++++++--- > posix/bits/types.h | 3 +- > sysdeps/mach/hurd/bits/typesizes.h | 1 + > .../unix/sysv/linux/alpha/bits/typesizes.h | 1 + > .../unix/sysv/linux/generic/bits/typesizes.h | 1 + > sysdeps/unix/sysv/linux/s390/bits/typesizes.h | 1 + > .../unix/sysv/linux/sparc/bits/typesizes.h | 1 + > sysdeps/unix/sysv/linux/x86/bits/typesizes.h | 1 + > time/Versions | 5 +++ > time/ctime.c | 21 ++++++++-- > time/ctime_r.c | 21 ++++++++-- > time/gmtime.c | 38 ++++++++++++++++--- > time/localtime.c | 36 ++++++++++++++++-- > time/offtime.c | 12 +++--- > time/tzfile.c | 14 ++----- > time/tzset.c | 30 ++++++--------- > 17 files changed, 160 insertions(+), 56 deletions(-) > Cordialement, Albert ARIBAUD 3ADEV
On Wed, 13 Jun 2018, Albert ARIBAUD wrote: > These patches have also been tested using build-many-glibcs.py, always > for x86_64, aarch64, arm and powerpc compilers, and regularly for all > compilers, and found to give the same results as those of the current > glibc master above which the patches were created. Since build-many-glibcs.py should give clean results everywhere except i686-gnu, and since this patch adds Versions entries at a public ABI version but has no *.abilist updates, I'm skeptical of the above description of testing. You should have no ABI test failures before the patch series, anywhere, whether in your normal ARM testing or with build-many-glibcs.py, and without *.abilist updates you should be seeing such failures after the patch series. Any patch adding new ABIs at public versions always needs to include the ABI baseline updates for *all* glibc configurations. You should do full execution testing for at least one 64-bit configuration, as well.
Hi Joseph, On Wed, 13 Jun 2018 14:08:16 +0000, Joseph Myers <joseph@codesourcery.com> wrote : > On Wed, 13 Jun 2018, Albert ARIBAUD wrote: > > > These patches have also been tested using build-many-glibcs.py, always > > for x86_64, aarch64, arm and powerpc compilers, and regularly for all > > compilers, and found to give the same results as those of the current > > glibc master above which the patches were created. > > Since build-many-glibcs.py should give clean results everywhere except > i686-gnu, and since this patch adds Versions entries at a public ABI > version but has no *.abilist updates, I'm skeptical of the above > description of testing. You should have no ABI test failures before the > patch series, anywhere, whether in your normal ARM testing or with > build-many-glibcs.py, and without *.abilist updates you should be seeing > such failures after the patch series. > > Any patch adding new ABIs at public versions always needs to include the > ABI baseline updates for *all* glibc configurations. Right now I only update abilists for ARM and PowerPC as these are the ones for which I run functional testing. I can update others but I won't be able to test them functionally. In any case, I'll group together related changes to Versions and abilists in the same patch. > You should do full execution testing for at least one 64-bit > configuration, as well. My minimal set includes x86_64-linux-gnu, aarch64-linux-gnu, arm-linux-gnueabi and powerpc-linux-gnu, so this covers two different 64-bit configurations. (my maximal set is 'all compilers and all glibcs' -- including i686-gnu for the sake of it -- but as this takes around 30 hours on a reasonably fast machine, I don't run it for every change.) Cordialement, Albert ARIBAUD 3ADEV