Message ID | 20200508145640.16336-7-lukma@denx.de |
---|---|
State | Committed |
Delegated to: | Lukasz Majewski |
Headers |
Return-Path: <libc-alpha-bounces@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 32F85397280A; Fri, 8 May 2020 14:57:13 +0000 (GMT) X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-out.m-online.net (mail-out.m-online.net [IPv6:2001:a60:0:28:0:1:25:1]) by sourceware.org (Postfix) with ESMTPS id 660B53851C1C for <libc-alpha@sourceware.org>; Fri, 8 May 2020 14:57:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 660B53851C1C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=lukma@denx.de Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 49JYMT49W1z1rt4X; Fri, 8 May 2020 16:57:09 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 49JYMT3R8Qz1r79j; Fri, 8 May 2020 16:57:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id kh7lADTDGSIp; Fri, 8 May 2020 16:57:07 +0200 (CEST) X-Auth-Info: UJkdod8CUVf+SbeCjzwcfY5IwxVJjoj3W23V1XXOTJI= Received: from localhost.localdomain (85-222-111-42.dynamic.chello.pl [85.222.111.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Fri, 8 May 2020 16:57:07 +0200 (CEST) From: Lukasz Majewski <lukma@denx.de> To: Joseph Myers <joseph@codesourcery.com>, Adhemerval Zanella <adhemerval.zanella@linaro.org> Subject: [PATCH v2 6/7] y2038: linux: Provide __ntp_gettime64 implementation Date: Fri, 8 May 2020 16:56:39 +0200 Message-Id: <20200508145640.16336-7-lukma@denx.de> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200508145640.16336-1-lukma@denx.de> References: <20200508145640.16336-1-lukma@denx.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-22.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <http://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <http://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> Cc: Florian Weimer <fweimer@redhat.com>, GNU C Library <libc-alpha@sourceware.org>, Andreas Schwab <schwab@suse.de>, Alistair Francis <alistair.francis@wdc.com> Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
y2038: Convert clock_adjtime related syscalls to support 64 bit time
|
|
Commit Message
Lukasz Majewski
May 8, 2020, 2:56 p.m. UTC
This patch provides new __ntp_gettime64 explicit 64 bit function for getting time parameters via NTP interface. Internally, the __clock_adjtime64 syscall is used instead of __adjtimex. This patch is necessary for having architectures with __WORDSIZE == 32 Y2038 safe. Moreover, a 32 bit version - __ntp_gettime has been refactored to internally use __ntp_gettime64. The __ntp_gettime is now supposed to be used on systems still supporting 32 bit time (__TIMESIZE != 64) - hence the necessary conversions between struct ntptimeval and 64 bit struct __ntptimeval64. Build tests: ./src/scripts/build-many-glibcs.py glibcs Run-time tests: - Run specific tests on ARM/x86 32bit systems (qemu): https://github.com/lmajewski/meta-y2038 and run tests: https://github.com/lmajewski/y2038-tests/commits/master Above tests were performed with Y2038 redirection applied as well as without to test the proper usage of both __ntp_gettime64 and __ntp_gettime. --- sysdeps/unix/sysv/linux/include/sys/timex.h | 4 ++++ sysdeps/unix/sysv/linux/ntp_gettime.c | 24 ++++++++++++++++++--- 2 files changed, 25 insertions(+), 3 deletions(-)
Comments
On 08/05/2020 11:56, Lukasz Majewski wrote: > This patch provides new __ntp_gettime64 explicit 64 bit function for getting > time parameters via NTP interface. > > Internally, the __clock_adjtime64 syscall is used instead of __adjtimex. This > patch is necessary for having architectures with __WORDSIZE == 32 Y2038 safe. > > Moreover, a 32 bit version - __ntp_gettime has been refactored to internally > use __ntp_gettime64. > > The __ntp_gettime is now supposed to be used on systems still supporting 32 > bit time (__TIMESIZE != 64) - hence the necessary conversions between struct > ntptimeval and 64 bit struct __ntptimeval64. > > Build tests: > ./src/scripts/build-many-glibcs.py glibcs > > Run-time tests: > - Run specific tests on ARM/x86 32bit systems (qemu): > https://github.com/lmajewski/meta-y2038 and run tests: > https://github.com/lmajewski/y2038-tests/commits/master > > Above tests were performed with Y2038 redirection applied as well as without to > test the proper usage of both __ntp_gettime64 and __ntp_gettime. Ok with a doubt below. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> > --- > sysdeps/unix/sysv/linux/include/sys/timex.h | 4 ++++ > sysdeps/unix/sysv/linux/ntp_gettime.c | 24 ++++++++++++++++++--- > 2 files changed, 25 insertions(+), 3 deletions(-) > > diff --git a/sysdeps/unix/sysv/linux/include/sys/timex.h b/sysdeps/unix/sysv/linux/include/sys/timex.h > index e762e03230..ef53515803 100644 > --- a/sysdeps/unix/sysv/linux/include/sys/timex.h > +++ b/sysdeps/unix/sysv/linux/include/sys/timex.h > @@ -33,6 +33,7 @@ libc_hidden_proto (__adjtimex) > # define __clock_adjtime64 __clock_adjtime > # define ___adjtimex64 ___adjtimex > # define __ntptimeval64 ntptimeval > +# define __ntp_gettime64 __ntp_gettime > # else > > struct __timex64 > @@ -91,6 +92,9 @@ struct __ntptimeval64 > long int __glibc_reserved3; > long int __glibc_reserved4; > }; > +extern int __ntp_gettime64 (struct __ntptimeval64 *ntv); > +libc_hidden_proto (__ntp_gettime64) > + > # endif > > /* Convert a known valid struct timex into a struct __timex64. */ Ok. > diff --git a/sysdeps/unix/sysv/linux/ntp_gettime.c b/sysdeps/unix/sysv/linux/ntp_gettime.c > index c8d6a197dc..21aeffadeb 100644 > --- a/sysdeps/unix/sysv/linux/ntp_gettime.c > +++ b/sysdeps/unix/sysv/linux/ntp_gettime.c > @@ -17,6 +17,7 @@ > > #define ntp_gettime ntp_gettime_redirect > > +#include <time.h> > #include <sys/timex.h> > > #undef ntp_gettime > @@ -27,15 +28,32 @@ > > > int > -ntp_gettime (struct ntptimeval *ntv) > +__ntp_gettime64 (struct __ntptimeval64 *ntv) > { > - struct timex tntx; > + struct __timex64 tntx; > int result; > > tntx.modes = 0; > - result = __adjtimex (&tntx); > + result = __clock_adjtime64 (CLOCK_REALTIME, &tntx); > ntv->time = tntx.time; > ntv->maxerror = tntx.maxerror; > ntv->esterror = tntx.esterror; > return result; > } Ok. Maybe add a comment stating that using CLOCK_REALTIME should not make the function fail with EINVAL, ENODEV, or EOPNOTSUPP. I am not sure about EPERM in this situation, should we check for that and avoid seeting NTV in such situation? > + > +#if __TIMESIZE != 64 > +libc_hidden_def (__ntp_gettime64) > + > +int > +__ntp_gettime (struct ntptimeval *ntv) > +{ > + struct __ntptimeval64 ntv64; > + int result; > + > + result = __ntp_gettime64 (&ntv64); > + *ntv = valid_ntptimeval64_to_ntptimeval (ntv64); > + > + return result; > +} > +#endif > +strong_alias (__ntp_gettime, ntp_gettime) > Ok.
Hi Adhemerval, > On 08/05/2020 11:56, Lukasz Majewski wrote: > > This patch provides new __ntp_gettime64 explicit 64 bit function > > for getting time parameters via NTP interface. > > > > Internally, the __clock_adjtime64 syscall is used instead of > > __adjtimex. This patch is necessary for having architectures with > > __WORDSIZE == 32 Y2038 safe. > > > > Moreover, a 32 bit version - __ntp_gettime has been refactored to > > internally use __ntp_gettime64. > > > > The __ntp_gettime is now supposed to be used on systems still > > supporting 32 bit time (__TIMESIZE != 64) - hence the necessary > > conversions between struct ntptimeval and 64 bit struct > > __ntptimeval64. > > > > Build tests: > > ./src/scripts/build-many-glibcs.py glibcs > > > > Run-time tests: > > - Run specific tests on ARM/x86 32bit systems (qemu): > > https://github.com/lmajewski/meta-y2038 and run tests: > > https://github.com/lmajewski/y2038-tests/commits/master > > > > Above tests were performed with Y2038 redirection applied as well > > as without to test the proper usage of both __ntp_gettime64 and > > __ntp_gettime. > > Ok with a doubt below. > > Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> > > > --- > > sysdeps/unix/sysv/linux/include/sys/timex.h | 4 ++++ > > sysdeps/unix/sysv/linux/ntp_gettime.c | 24 > > ++++++++++++++++++--- 2 files changed, 25 insertions(+), 3 > > deletions(-) > > > > diff --git a/sysdeps/unix/sysv/linux/include/sys/timex.h > > b/sysdeps/unix/sysv/linux/include/sys/timex.h index > > e762e03230..ef53515803 100644 --- > > a/sysdeps/unix/sysv/linux/include/sys/timex.h +++ > > b/sysdeps/unix/sysv/linux/include/sys/timex.h @@ -33,6 +33,7 @@ > > libc_hidden_proto (__adjtimex) # define __clock_adjtime64 > > __clock_adjtime # define ___adjtimex64 ___adjtimex > > # define __ntptimeval64 ntptimeval > > +# define __ntp_gettime64 __ntp_gettime > > # else > > > > struct __timex64 > > @@ -91,6 +92,9 @@ struct __ntptimeval64 > > long int __glibc_reserved3; > > long int __glibc_reserved4; > > }; > > +extern int __ntp_gettime64 (struct __ntptimeval64 *ntv); > > +libc_hidden_proto (__ntp_gettime64) > > + > > # endif > > > > /* Convert a known valid struct timex into a struct __timex64. */ > > > > Ok. > > > diff --git a/sysdeps/unix/sysv/linux/ntp_gettime.c > > b/sysdeps/unix/sysv/linux/ntp_gettime.c index > > c8d6a197dc..21aeffadeb 100644 --- > > a/sysdeps/unix/sysv/linux/ntp_gettime.c +++ > > b/sysdeps/unix/sysv/linux/ntp_gettime.c @@ -17,6 +17,7 @@ > > > > #define ntp_gettime ntp_gettime_redirect > > > > +#include <time.h> > > #include <sys/timex.h> > > > > #undef ntp_gettime > > @@ -27,15 +28,32 @@ > > > > > > int > > -ntp_gettime (struct ntptimeval *ntv) > > +__ntp_gettime64 (struct __ntptimeval64 *ntv) > > { > > - struct timex tntx; > > + struct __timex64 tntx; > > int result; > > > > tntx.modes = 0; > > - result = __adjtimex (&tntx); > > + result = __clock_adjtime64 (CLOCK_REALTIME, &tntx); > > ntv->time = tntx.time; > > ntv->maxerror = tntx.maxerror; > > ntv->esterror = tntx.esterror; > > return result; > > } > > Ok. Maybe add a comment stating that using CLOCK_REALTIME should > not make the function fail with EINVAL, ENODEV, or EOPNOTSUPP. > I am not sure about EPERM in this situation, should we check for > that and avoid seeting NTV in such situation? > I will add following comment: /* Using the CLOCK_REALTIME with __clock_adjtime64 (as a replacement for Y2038 unsafe adjtimex) will not make the function fail with EINVAL, ENODEV, or EOPNOTSUPP. */ Regarding the EPERM: The adjtimex also could return EPERM: http://man7.org/linux/man-pages/man2/adjtimex.2.html which would be propagated to caller of ntp_gettime. In this case the ntv structure would get updated. If we want to preserve the same behavior, it would be correct to leave the code as is (and ntv would get updated anyway). > > + > > +#if __TIMESIZE != 64 > > +libc_hidden_def (__ntp_gettime64) > > + > > +int > > +__ntp_gettime (struct ntptimeval *ntv) > > +{ > > + struct __ntptimeval64 ntv64; > > + int result; > > + > > + result = __ntp_gettime64 (&ntv64); > > + *ntv = valid_ntptimeval64_to_ntptimeval (ntv64); > > + > > + return result; > > +} > > +#endif > > +strong_alias (__ntp_gettime, ntp_gettime) > > > > Ok. 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
On 19/05/2020 17:20, Lukasz Majewski wrote: > Hi Adhemerval, > >> On 08/05/2020 11:56, Lukasz Majewski wrote: >>> This patch provides new __ntp_gettime64 explicit 64 bit function >>> for getting time parameters via NTP interface. >>> >>> Internally, the __clock_adjtime64 syscall is used instead of >>> __adjtimex. This patch is necessary for having architectures with >>> __WORDSIZE == 32 Y2038 safe. >>> >>> Moreover, a 32 bit version - __ntp_gettime has been refactored to >>> internally use __ntp_gettime64. >>> >>> The __ntp_gettime is now supposed to be used on systems still >>> supporting 32 bit time (__TIMESIZE != 64) - hence the necessary >>> conversions between struct ntptimeval and 64 bit struct >>> __ntptimeval64. >>> >>> Build tests: >>> ./src/scripts/build-many-glibcs.py glibcs >>> >>> Run-time tests: >>> - Run specific tests on ARM/x86 32bit systems (qemu): >>> https://github.com/lmajewski/meta-y2038 and run tests: >>> https://github.com/lmajewski/y2038-tests/commits/master >>> >>> Above tests were performed with Y2038 redirection applied as well >>> as without to test the proper usage of both __ntp_gettime64 and >>> __ntp_gettime. >> >> Ok with a doubt below. >> >> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> >> >>> --- >>> sysdeps/unix/sysv/linux/include/sys/timex.h | 4 ++++ >>> sysdeps/unix/sysv/linux/ntp_gettime.c | 24 >>> ++++++++++++++++++--- 2 files changed, 25 insertions(+), 3 >>> deletions(-) >>> >>> diff --git a/sysdeps/unix/sysv/linux/include/sys/timex.h >>> b/sysdeps/unix/sysv/linux/include/sys/timex.h index >>> e762e03230..ef53515803 100644 --- >>> a/sysdeps/unix/sysv/linux/include/sys/timex.h +++ >>> b/sysdeps/unix/sysv/linux/include/sys/timex.h @@ -33,6 +33,7 @@ >>> libc_hidden_proto (__adjtimex) # define __clock_adjtime64 >>> __clock_adjtime # define ___adjtimex64 ___adjtimex >>> # define __ntptimeval64 ntptimeval >>> +# define __ntp_gettime64 __ntp_gettime >>> # else >>> >>> struct __timex64 >>> @@ -91,6 +92,9 @@ struct __ntptimeval64 >>> long int __glibc_reserved3; >>> long int __glibc_reserved4; >>> }; >>> +extern int __ntp_gettime64 (struct __ntptimeval64 *ntv); >>> +libc_hidden_proto (__ntp_gettime64) >>> + >>> # endif >>> >>> /* Convert a known valid struct timex into a struct __timex64. */ >>> >> >> Ok. >> >>> diff --git a/sysdeps/unix/sysv/linux/ntp_gettime.c >>> b/sysdeps/unix/sysv/linux/ntp_gettime.c index >>> c8d6a197dc..21aeffadeb 100644 --- >>> a/sysdeps/unix/sysv/linux/ntp_gettime.c +++ >>> b/sysdeps/unix/sysv/linux/ntp_gettime.c @@ -17,6 +17,7 @@ >>> >>> #define ntp_gettime ntp_gettime_redirect >>> >>> +#include <time.h> >>> #include <sys/timex.h> >>> >>> #undef ntp_gettime >>> @@ -27,15 +28,32 @@ >>> >>> >>> int >>> -ntp_gettime (struct ntptimeval *ntv) >>> +__ntp_gettime64 (struct __ntptimeval64 *ntv) >>> { >>> - struct timex tntx; >>> + struct __timex64 tntx; >>> int result; >>> >>> tntx.modes = 0; >>> - result = __adjtimex (&tntx); >>> + result = __clock_adjtime64 (CLOCK_REALTIME, &tntx); >>> ntv->time = tntx.time; >>> ntv->maxerror = tntx.maxerror; >>> ntv->esterror = tntx.esterror; >>> return result; >>> } >> >> Ok. Maybe add a comment stating that using CLOCK_REALTIME should >> not make the function fail with EINVAL, ENODEV, or EOPNOTSUPP. >> I am not sure about EPERM in this situation, should we check for >> that and avoid seeting NTV in such situation? >> > > I will add following comment: > > /* Using the CLOCK_REALTIME with __clock_adjtime64 (as a replacement > for Y2038 unsafe adjtimex) will not make the function fail with EINVAL, > ENODEV, or EOPNOTSUPP. */ Maybe: /* clock_adjtime64 with CLOCK_REALTIME does not trigger EINVAL, ENODEV, or EOPNOTSUPP. It might still trigger EPERM. */ > > Regarding the EPERM: > > The adjtimex also could return EPERM: > http://man7.org/linux/man-pages/man2/adjtimex.2.html > > which would be propagated to caller of ntp_gettime. In this case the > ntv structure would get updated. > > If we want to preserve the same behavior, it would be correct to leave > the code as is (and ntv would get updated anyway). Alight, we can track this in another patch. > >>> + >>> +#if __TIMESIZE != 64 >>> +libc_hidden_def (__ntp_gettime64) >>> + >>> +int >>> +__ntp_gettime (struct ntptimeval *ntv) >>> +{ >>> + struct __ntptimeval64 ntv64; >>> + int result; >>> + >>> + result = __ntp_gettime64 (&ntv64); >>> + *ntv = valid_ntptimeval64_to_ntptimeval (ntv64); >>> + >>> + return result; >>> +} >>> +#endif >>> +strong_alias (__ntp_gettime, ntp_gettime) >>> >> >> Ok. > > > > > 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 >
I'm seeing build failures from build-many-glibcs.py for hppa, mips (n32), sh4, sparcv8, sparcv9, that appear to arise from one of these patches. ../sysdeps/unix/sysv/linux/ntp_gettime.c: In function '__ntp_gettime': ../sysdeps/unix/sysv/linux/ntp_gettime.c:56:10: error: 'ntv64.tai' is used uninitialized in this function [-Werror=uninitialized] 56 | *ntv = valid_ntptimeval64_to_ntptimeval (ntv64); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ https://sourceware.org/pipermail/libc-testresults/2020q2/006191.html
Hi Joseph, > I'm seeing build failures from build-many-glibcs.py for hppa, mips > (n32), sh4, sparcv8, sparcv9, that appear to arise from one of these > patches. > > ../sysdeps/unix/sysv/linux/ntp_gettime.c: In function '__ntp_gettime': > ../sysdeps/unix/sysv/linux/ntp_gettime.c:56:10: error: 'ntv64.tai' is > used uninitialized in this function [-Werror=uninitialized] 56 | > *ntv = valid_ntptimeval64_to_ntptimeval (ntv64); | > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > https://sourceware.org/pipermail/libc-testresults/2020q2/006191.html > Thanks for spotting it. I'm wondering if those archs use different set of gcc switches for compilation? And another question (I think related) - after updating the the glibc -master (there was a switch to gcc 10 for build-many-glibc.py) I do have an issue with "check-compilers" task on those archs. Joseph, do you use updated setup? 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
On Wed, 20 May 2020, Lukasz Majewski wrote: > I'm wondering if those archs use different set of gcc switches for > compilation? No. But there are various architecture-specific aspects to optimization that may result in warnings showing up on only some architectures. Florian has fixed this bug. > And another question (I think related) - after updating the the glibc > -master (there was a switch to gcc 10 for build-many-glibc.py) I do have > an issue with "check-compilers" task on those archs. A check-compilers failure simply means that one of the tasks from the "compilers" run failed. In general, if you did a "compilers" run when the build was broken, you will have an incomplete set of compilers that isn't good for testing subsequent glibc changes and will need to rerun "compilers" with the source trees in an unbroken state. > Joseph, do you use updated setup? My bots using GCC release branches only rebuild "compilers" once a week. That means a short-lived glibc build breakage is likely to show up as a failure in "glibcs" rather than "compilers" (but if the build is broken at the wrong time, when "compilers" runs, the "glibcs" builds will be using the broken compilers for a week). My bot using GCC master rebuilds the compilers every time (but only runs once a day, whereas the ones using GCC release branches will run more frequently if there are new glibc changes to test).
Hi Joseph, > On Wed, 20 May 2020, Lukasz Majewski wrote: > > > I'm wondering if those archs use different set of gcc switches for > > compilation? > > No. But there are various architecture-specific aspects to > optimization that may result in warnings showing up on only some > architectures. > > Florian has fixed this bug. > > > And another question (I think related) - after updating the the > > glibc -master (there was a switch to gcc 10 for > > build-many-glibc.py) I do have an issue with "check-compilers" task > > on those archs. > > A check-compilers failure simply means that one of the tasks from the > "compilers" run failed. > > In general, if you did a "compilers" run when the build was broken, > you will have an incomplete set of compilers that isn't good for > testing subsequent glibc changes and will need to rerun "compilers" > with the source trees in an unbroken state. Yes, you are 100% correct. That was the case - I wanted to rebuild compilers after update to gcc 10 for build-many-glibc.py. As a result I used the broken glibc for building compilers. Thanks for explanation. > > > Joseph, do you use updated setup? > > My bots using GCC release branches only rebuild "compilers" once a > week. That means a short-lived glibc build breakage is likely to show > up as a failure in "glibcs" rather than "compilers" (but if the build > is broken at the wrong time, when "compilers" runs, the "glibcs" > builds will be using the broken compilers for a week). > > My bot using GCC master rebuilds the compilers every time (but only > runs once a day, whereas the ones using GCC release branches will run > more frequently if there are new glibc changes to test). > 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
diff --git a/sysdeps/unix/sysv/linux/include/sys/timex.h b/sysdeps/unix/sysv/linux/include/sys/timex.h index e762e03230..ef53515803 100644 --- a/sysdeps/unix/sysv/linux/include/sys/timex.h +++ b/sysdeps/unix/sysv/linux/include/sys/timex.h @@ -33,6 +33,7 @@ libc_hidden_proto (__adjtimex) # define __clock_adjtime64 __clock_adjtime # define ___adjtimex64 ___adjtimex # define __ntptimeval64 ntptimeval +# define __ntp_gettime64 __ntp_gettime # else struct __timex64 @@ -91,6 +92,9 @@ struct __ntptimeval64 long int __glibc_reserved3; long int __glibc_reserved4; }; +extern int __ntp_gettime64 (struct __ntptimeval64 *ntv); +libc_hidden_proto (__ntp_gettime64) + # endif /* Convert a known valid struct timex into a struct __timex64. */ diff --git a/sysdeps/unix/sysv/linux/ntp_gettime.c b/sysdeps/unix/sysv/linux/ntp_gettime.c index c8d6a197dc..21aeffadeb 100644 --- a/sysdeps/unix/sysv/linux/ntp_gettime.c +++ b/sysdeps/unix/sysv/linux/ntp_gettime.c @@ -17,6 +17,7 @@ #define ntp_gettime ntp_gettime_redirect +#include <time.h> #include <sys/timex.h> #undef ntp_gettime @@ -27,15 +28,32 @@ int -ntp_gettime (struct ntptimeval *ntv) +__ntp_gettime64 (struct __ntptimeval64 *ntv) { - struct timex tntx; + struct __timex64 tntx; int result; tntx.modes = 0; - result = __adjtimex (&tntx); + result = __clock_adjtime64 (CLOCK_REALTIME, &tntx); ntv->time = tntx.time; ntv->maxerror = tntx.maxerror; ntv->esterror = tntx.esterror; return result; } + +#if __TIMESIZE != 64 +libc_hidden_def (__ntp_gettime64) + +int +__ntp_gettime (struct ntptimeval *ntv) +{ + struct __ntptimeval64 ntv64; + int result; + + result = __ntp_gettime64 (&ntv64); + *ntv = valid_ntptimeval64_to_ntptimeval (ntv64); + + return result; +} +#endif +strong_alias (__ntp_gettime, ntp_gettime)