From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 8B9F51F463 for ; Fri, 13 Sep 2019 14:36:48 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type; q=dns; s=default; b=MHPxs dkNtslLSeKC+3AZWwWkfEyDqhbaUi3QhvwgII0pp2k4vNaUqyxeIkzi+fDgK79BV hEI+nofBbLemVhzGbTtZ9Ei+OHfSotRju1N5rzehmeWLK2fZMQPLy/vwP0HqNW6w A3AcGvoKJH5pq3AetuAfCBSvdCdR5brySrn738= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type; s=default; bh=tYK5rjoJEqw BfNgFjlsWMMfplMo=; b=gg1c32rtyBc6PwFauVuL5zQnuiL8uJDwn0xWsSvhdcr sNOXnes2HDKVDI7v/OHl/SABiKyOFg7ZNslRdQ+TvpY41730+gKwnZHrA2qFyPq5 XTCkUw8XeOumXgofmRRFvG4D/1Z8ba3svGw3zeULYhVpfvvi2ftZnn1nj8mBi0aY = Received: (qmail 106944 invoked by alias); 13 Sep 2019 14:36:46 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 106935 invoked by uid 89); 13 Sep 2019 14:36:46 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-out.m-online.net Date: Fri, 13 Sep 2019 16:36:31 +0200 From: Lukasz Majewski To: Alistair Francis Cc: Joseph Myers , Zack Weinberg , Arnd Bergmann , Alistair Francis , GNU C Library , Adhemerval Zanella , Florian Weimer , "Carlos O'Donell" , Stepan Golosunov Subject: Re: [PATCH v7 0/3] y2038: Linux: Introduce __clock_settime64 function Message-ID: <20190913163631.0814068c@jawa> In-Reply-To: References: <20190906145911.30207-1-lukma@denx.de> <20190906235542.1637b4c0@jawa> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/J9q8xhC3CE6dbP4fz_srCfG"; protocol="application/pgp-signature" --Sig_/J9q8xhC3CE6dbP4fz_srCfG Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Alistair, > On Fri, Sep 6, 2019 at 2:55 PM Lukasz Majewski wrote: > > > > Hi Alistair, > > =20 > > > On Fri, Sep 6, 2019 at 7:59 AM Lukasz Majewski > > > wrote: =20 > > > > > > > > This patch set introduces the conversion of clock_settime to > > > > explicit 64 bit struct __timespec64 arguments. As a result this > > > > function is now Y2038 safe. > > > > > > > > This work is (loosely) based on a previous development/patches: > > > > https://libc-alpha.sourceware.narkive.com/zniMOWui/rfc-patch-00-52-= make-glibc-y2038-proof#post68 > > > > > > > > Github branch (including the y2038 conversion example): > > > > https://github.com/lmajewski/y2038_glibc/commits/glibc__clock_setti= me-conversion-v7 > > > > > > > > Those patches have been applied on top of master branch: > > > > SHA1: a26918cfda4bc4b9dad8aae1496e3ef7cbb63d96 > > > > > > > > Shall be used with provided meta-y2038 for development and > > > > testing: https://github.com/lmajewski/meta-y2038 > > > > > > > > I've used guidelines from: > > > > https://www.gnu.org/software/libc/manual/html_mono/libc.html > > > > "D.2.1 64-bit time symbol handling in the GNU C Library" > > > > to convert *clock_settime*. > > > > > > > > and most notably from: > > > > https://sourceware.org/glibc/wiki/Y2038ProofnessDesign#clock_gettim= e.28.29 > > > > =20 > > > > > > Thanks for the patches Lukassz! > > > > > > With my RV32 port I see this failure when compiling: > > > =20 > > > > But I did not change the core code between v5 (to which you refer > > here): https://patchwork.ozlabs.org/cover/1155397/ > > and then: > > https://sourceware.org/ml/libc-alpha/2019-05/msg00661.html > > > > and v7: > > https://patchwork.ozlabs.org/patch/1159056/ > > > > (The only change in v6 was to use 32 bit call to clock_settime > > syscall as requested by Arnd to facilitate validation on existing > > systems. However, Joseph was against this change). > > > > The notable change (but not in this patch set) was moving > > clock_settime symbol solely to glibc (and it has been removed from > > librt).=20 >=20 > Yes, I have had this issue for awhile. >=20 > > > In file included from ../sysdeps/generic/hp-timing.h:23, > > > from ../nptl/descr.h:27, > > > from ../sysdeps/riscv/nptl/tls.h:41, > > > from ../include/errno.h:25, > > > from > > > ../sysdeps/unix/sysv/linux/clock_settime.c:18: > > > ../include/time.h:129:28: error: conflicting types for > > > '__clock_settime' # define __clock_settime64 __clock_settime > > > ^~~~~~~~~~~~~~~ ../sysdeps/unix/sysv/linux/clock_settime.c:25:1: > > > note: in expansion of macro '__clock_settime64' > > > __clock_settime64 (clockid_t clock_id, const struct __timespec64 > > > *tp) ^~~~~~~~~~~~~~~~~ > > > In file included from : > > > ../include/time.h:25:20: note: previous declaration of > > > '__clock_settime' was here > > > libc_hidden_proto (__clock_settime) > > > ^~~~~~~~~~~~~~~ > > > ./../include/libc-symbols.h:598:33: note: in definition of macro > > > '__hidden_proto' > > > extern thread __typeof (name) name __hidden_proto_hiddenattr > > > (attrs); ^~~~ > > > ./../include/libc-symbols.h:617:44: note: in expansion of macro > > > 'hidden_proto' # define libc_hidden_proto(name, attrs...) > > > hidden_proto (name, ##attrs) ^~~~~~~~~~~~ > > > ../include/time.h:25:1: note: in expansion of macro > > > 'libc_hidden_proto' libc_hidden_proto (__clock_settime) > > > ^~~~~~~~~~~~~~~~~ > > > ../sysdeps/unix/sysv/linux/clock_settime.c:70:42: error: > > > conflicting types for 'clock_settime' > > > versioned_symbol (libc, __clock_settime, clock_settime, > > > GLIBC_2_17); ^~~~~~~~~~~~~ > > > ./../include/libc-symbols.h:152:26: note: in definition of macro > > > '_weak_alias' extern __typeof (name) aliasname __attribute__ > > > ((weak, alias (#name))) \ ^~~~~~~~~ > > > ../include/shlib-compat.h:74:3: note: in expansion of macro > > > 'weak_alias' weak_alias (local, symbol) > > > ^~~~~~~~~~ > > > ../sysdeps/unix/sysv/linux/clock_settime.c:70:1: note: in > > > expansion of macro 'versioned_symbol' > > > versioned_symbol (libc, __clock_settime, clock_settime, > > > GLIBC_2_17); ^~~~~~~~~~~~~~~~ > > > In file included from ../include/time.h:2, > > > from ../sysdeps/generic/hp-timing.h:23, > > > from ../nptl/descr.h:27, > > > from ../sysdeps/riscv/nptl/tls.h:41, > > > from ../include/errno.h:25, > > > from > > > ../sysdeps/unix/sysv/linux/clock_settime.c:18: > > > ../time/time.h:222:12: note: previous declaration of > > > 'clock_settime' was here extern int clock_settime (clockid_t > > > __clock_id, const struct timespec *__tp) > > > > > > Which I can fix with this diff: > > > > > > diff --git a/include/time.h b/include/time.h > > > index 7ed3aa61d1d..28e2722de21 100644 > > > --- a/include/time.h > > > +++ b/include/time.h > > > @@ -125,13 +125,9 @@ extern __time64_t __timegm64 (struct tm > > > *__tp) __THROW; libc_hidden_proto (__timegm64) > > > #endif > > > > > > -#if __TIMESIZE =3D=3D 64 =20 > > > > What is the value of __TIMESIZE on your port? Is it 32 or 64 ? =20 >=20 > It's 64. >=20 > > > > Do you also #define __USE_TIME_BITS64 1 ? =20 >=20 > I don't. I can try with that, but I don't see if defined in the > source. Alistair, have you managed to make your patches working on top of this series? >=20 > Alistair >=20 > > =20 > > > -# define __clock_settime64 __clock_settime > > > -#else > > > extern int __clock_settime64 (clockid_t clock_id, > > > const struct __timespec64 *tp); > > > libc_hidden_proto (__clock_settime64) > > > -#endif > > > > > > /* Compute the `struct tm' representation of T, > > > offset OFFSET seconds east of UTC, > > > diff --git a/sysdeps/unix/sysv/linux/clock_settime.c > > > b/sysdeps/unix/sysv/linux/clock_settime.c > > > index f5e084238a5..ab033c56ea9 100644 > > > --- a/sysdeps/unix/sysv/linux/clock_settime.c > > > +++ b/sysdeps/unix/sysv/linux/clock_settime.c > > > @@ -54,7 +54,6 @@ __clock_settime64 (clockid_t clock_id, const > > > struct __timespec64 *tp) > > > #endif > > > } > > > > > > -#if __TIMESIZE !=3D 64 =20 > > > > When I look on RISC-V patchset: > > https://patchwork.ozlabs.org/patch/1155391/ > > > > for the __clock_nanosleep for example you follow the same > > convention. And you don't need to remove #if __TIMESIZE !=3D 64 for > > example. > > > > One difference is that the clock_settime64 code will be Y2038 on > > e.g. 32 bit ARM only when I apply on top of it following patch: > > https://github.com/lmajewski/y2038_glibc/commit/c6740c05ea9b224a552847d= 10402f98da8376994 > > > > (it enables redirect for clock_settime and support for > > -D_TIME_BITS=3D64 compilation flag). > > > > > > =20 > > > int > > > __clock_settime (clockid_t clock_id, const struct timespec *tp) > > > { > > > @@ -63,7 +62,6 @@ __clock_settime (clockid_t clock_id, const > > > struct timespec *tp) > > > valid_timespec_to_timespec64 (tp, &ts64); > > > return __clock_settime64 (clock_id, &ts64); > > > } > > > -#endif > > > > > > libc_hidden_def (__clock_settime) > > > > > > Alistair > > > =20 > > > > > > > > > > > > Lukasz Majewski (3): > > > > y2038: Introduce internal for glibc struct __timespec64 > > > > y2038: Provide conversion helpers for struct __timespec64 > > > > y2038: linux: Provide __clock_settime64 implementation > > > > > > > > include/time.h | 116 > > > > ++++++++++++++++++++++++ > > > > sysdeps/unix/sysv/linux/clock_settime.c | 38 +++++++- 2 files > > > > changed, 150 insertions(+), 4 deletions(-) > > > > > > > > -- > > > > 2.20.1 > > > > =20 > > > > > > > > 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 =20 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 --Sig_/J9q8xhC3CE6dbP4fz_srCfG Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAl17qW8ACgkQAR8vZIA0 zr2fPwgAgVwdbvGLDxUztAeKYie20++6zpQHs8ooOiRNtxkKtxi11HvUSbfofHkM i/PxzpgTr2iryrIre+kaHwWsYQYD8MJz4ofFAAHV8F7Nn4wbSShqmZ3e5ghSrVXA vz6UOX+HPVg+NA7ssNzJ6Gv5FYkZoeTIla85Js8OjLVYP6PDKuYqyGpK92sNWczT DH8ZKLtGmv5w4xpsEs4R2DkNUUaEu7NKKSJtcg+kXNMTSc69NjJEWfOlbyuLMZiE 8s1wlN2QkYqg2cUM925Q869wcKBI0onGW8gfaL/lClJ7ojldivaJr1Npm0sMk3IQ r3wqZK8wGDnIXjwzFIqbCTzXHxATIQ== =Xud5 -----END PGP SIGNATURE----- --Sig_/J9q8xhC3CE6dbP4fz_srCfG--