From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by sourceware.org (Postfix) with ESMTPS id CDB5B3858001 for ; Wed, 13 Oct 2021 11:44:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CDB5B3858001 Received: by mail-ed1-x52b.google.com with SMTP id d3so9025866edp.3 for ; Wed, 13 Oct 2021 04:44:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CHAWPKXdVqsKx7dL+R16dgWy12InCDHO5VA52x0z/AI=; b=PHk2Ey59FdKA0CzFARNxPXx/2t9NG7wfsyu9dzGywUXK8nUeGlXaA/YcLmkQxx2f9L 3E4rTj0c6fM7RDOACMuAyaUaX7h+daZfZ6qMLeirK1450xHqum4Mk9FVTM6STDO/OBKl dCAutez/Do90T8s8jGafnJKiMw8Q032ySraAM7YV909qJKMZWh2gVqXhToa7BcEZfwaV PuKqXqH4C26WoGDDQpt67wmBxzd4cPxWphW4lSZVCihA0TaxMvcdaoM9XE0HdP18hjlu GkURiHz+xMljwSYgPRfzkL/90stnoKwEBQHV7pyzZ1bR/psSHu788LFmpLGBmLTa23Jv RBoQ== X-Gm-Message-State: AOAM531XsYLL7/+zy9e2CPOHOeq78hzLBeI+FWS0Q/KLvDSTcVP58y/M JyNA7CuV9KnProE3jRRtb4yi0Lqrc59Vx3UL4uOIH+pmkPE= X-Google-Smtp-Source: ABdhPJwtXlOhg7RrlcLtl2wWwd4yK0+HLCBetGfpVsF3cibHakDvwK8qALgtf8dudoVrFkbss+ga9ea3yYhYzq35OUQ= X-Received: by 2002:aa7:c78f:: with SMTP id n15mr9159497eds.338.1634125492637; Wed, 13 Oct 2021 04:44:52 -0700 (PDT) MIME-Version: 1.0 References: <20210607203613.282543-1-adhemerval.zanella@linaro.org> <20210607203613.282543-19-adhemerval.zanella@linaro.org> In-Reply-To: <20210607203613.282543-19-adhemerval.zanella@linaro.org> From: Stafford Horne Date: Wed, 13 Oct 2021 20:44:41 +0900 Message-ID: Subject: Re: [PATCH v3 18/24] y2038: Add support for 64-bit time on legacy ABIs To: Adhemerval Zanella Cc: GLIBC patches X-Spam-Status: No, score=-9.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, HTML_MESSAGE, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 11:44:56 -0000 Hello, Sorry, for bringing up this old patch I have recently rebased my OpenRISC port onto the latest glibc master and this seems to be causing issues. Without doing any changes to my build (i.e. not touching _TIME_BITS) I am able to build everything find but getting the following test failures: FAIL: misc/tst-ntp_gettime FAIL: misc/tst-ntp_gettimex This is traced back to glibc using 32 bit words in the timex structure in sysdeps/unix/sysv/linux/bits/timex.h. I was able to hack around it by changing the #ifdef __USE_TIME_BITS64, to #if 1 and then the tests pass. See some comments below... On Tue, Jun 8, 2021 at 5:54 AM Adhemerval Zanella via Libc-alpha < libc-alpha@sourceware.org> wrote: > > A new build flag, _TIME_BITS, enables the usage of the newer 64-bit > time symbols for legacy ABI (where 32 bit time_t is default). The 64 > bit time support is only enabled if LFS (_FILE_OFFSET_BITS=64) is > also used. > > Different than LFS support, the y2038 symbols are added only for the > required ABIs (armhf, csky, hppa, i386, m68k, microblaze, mips32, > mips64-n32, nios2, powerpc32, sparc32, s390-32, and sh). The ABIs with > 64-bit time support are unchanged, both for symbol and types > redirection. > > On Linux the full 64-bit time support requires a minimum of kernel > version v5.1. Otherwise, the 32 bit fallbacks are used and might > results in error with overflow return code (EOVERFLOW). > > The i686-gnu does not yet support 64-bit time. [...] > --- a/NEWS > +++ b/NEWS > @@ -31,6 +31,11 @@ Major new features: > __STDC_WANT_IEC_60559_BFP_EXT__, as specified in TS 18661-1, is > defined, and when _GNU_SOURCE is defined. > > +* Add support for 64-bit time_t for ABIs with defaults to 32 bit time_t. > + This is enabled with the _TIME_BITS preprocessor set to 64 and only > + supported when LFS (_FILE_OFFSET_BITS=64) is also enabled. It is only > + enabled for Linux and the full support requires a minimum version of 5.1. > + Now, I am trying to build with CFLAGS="-g -Og -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64", but this is causing build failures. iofgetpos.c:84:40: error: conflicting types for 'fgetpos'; have 'int(FILE *, __fpos_t *)' {aka 'int(struct _IO_FILE *, struct _G _fpos_t *)'} 84 | versioned_symbol (libc, __new_fgetpos, fgetpos, GLIBC_2_2); | ^~~~~~~ ./../include/libc-symbols.h:155:26: note: in definition of macro '_weak_alias' 155 | extern __typeof (name) aliasname __attribute__ ((weak, alias (#name))) \ | ^~~~~~~~~ ../include/shlib-compat.h:117:3: note: in expansion of macro 'weak_alias' 117 | weak_alias (local, symbol) | ^~~~~~~~~~ iofgetpos.c:84:1: note: in expansion of macro 'versioned_symbol' 84 | versioned_symbol (libc, __new_fgetpos, fgetpos, GLIBC_2_2); | ^~~~~~~~~~~~~~~~ In file included from ../include/sys/cdefs.h:10, from ../include/features.h:488, from ../stdlib/errno.h:25, from ../include/errno.h:2, from libioP.h:40, from iofgetpos.c:34: ../libio/stdio.h:762:24: note: previous declaration of 'fgetpos' with type 'int(FILE * restrict, fpos_t * restrict)' {aka 'int( struct _IO_FILE * restrict, struct _G_fpos64_t * restrict)'} 762 | extern int __REDIRECT (fgetpos, (FILE *__restrict __stream, | ^~~~~~~ ../misc/sys/cdefs.h:198:41: note: in definition of macro '__REDIRECT' 198 | # define __REDIRECT(name, proto, alias) name proto __asm__ (__ASMNAME (#alias)) Trying to fix this I get further build failures ../sysdeps/unix/sysv/linux/globfree.c:28:23: error: 'globfree64' aliased to undefined symbol 'globfree' 28 | weak_alias (globfree, globfree64) | ^~~~~~~~~~ ./../include/libc-symbols.h:155:26: note: in definition of macro '_weak_alias' 155 | extern __typeof (name) aliasname __attribute__ ((weak, alias (#name))) \ | ^~~~~~~~~ ../sysdeps/unix/sysv/linux/globfree.c:28:1: note: in expansion of macro 'weak_alias' 28 | weak_alias (globfree, globfree64) | ^~~~~~~~~~ [...] > index 705a949089..9fa658e9a7 100644 > --- a/manual/creature.texi > +++ b/manual/creature.texi > @@ -165,6 +165,50 @@ This macro was introduced as part of the Large File Support extension > (LFS). > @end defvr > > +@defvr Macro _TIME_BITS > +This macro determines the bit size of @code{time_t} (and therefore the > +bit size of all @code{time_t} derived types and the prototypes of all > +related functions). If @code{_TIME_BITS} is undefined, the bit size of > +@code{time_t} is architecture dependent. > + > +Possible values of @code{_TIME_BITS}: > +@enumerate > +@item > +@code{_TIME_BITS=64} and port from the outset uses 64-bit > +@code{time_t} and word size equals to @w{64 bits} (e.g. x86_64) - no > +action > + > +@item > +@code{_TIME_BITS=32} and port from the outset uses 32-bit > +@code{time_t} and word size equals to @w{64 bits} (e.g. ARM) - no > +action > + > +@item > +@code{_TIME_BITS=64} and port from the outset uses 64-bit > +@code{time_t} and word size equals to @w{32 bits} (e.g. ARC, RV32) > +- no action OpenRISC falls into this category. We have 64-bit support but word size is 32 bits. What does "no action" mean here? Does it mean as long as I set _TIME_BITS=64 no extra porting effort is needed? > +@item > +@code{_TIME_BITS=64} and port from the outset uses 32-bit > +@code{time_t} and word size equals to @w{32 bits} (e.g. ARM) > +- the @code{time_t} is modified to be able to hold 64-bit time. > + > +@item > +For any other use case the compile-time error is emitted. > +@end enumerate > + > +The @code{_TIME_BITS} can be only used when @code{_FILE_OFFSET_BITS=64} > +is also defined. > + > +For the point @b{4} above, calls to proper syscalls depend on the > +Linux kernel version on which the system is running. For Linux kernel > +version above @b{5.1} syscalls supporting 64-bit time are used. Otherwise, > +a fallback code is used with legacy (i.e. 32-bit) syscalls. > + > +By using this macro certain ports gain support for 64-bit time and as > +a result become immune to Y2038 problem. > +@end defvr > + [...] > --- /dev/null > +++ b/sysdeps/unix/sysv/linux/features-time64.h > @@ -0,0 +1,37 @@ > +/* Features part to handle 64-bit time_t support. > + Copyright (C) 2021 Free Software Foundation, Inc. > + This file is part of the GNU C Library. > + > + The GNU C Library is free software; you can redistribute it and/or > + modify it under the terms of the GNU Lesser General Public > + License as published by the Free Software Foundation; either > + version 2.1 of the License, or (at your option) any later version. > + > + The GNU C Library is distributed in the hope that it will be useful, > + but WITHOUT ANY WARRANTY; without even the implied warranty of > + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + Lesser General Public License for more details. > + > + You should have received a copy of the GNU Lesser General Public > + License along with the GNU C Library; if not, see > + . */ > + > +/* We need to know the word size in order to check the time size. */ > +#include > +#include > + > +#if defined _TIME_BITS > +# if _TIME_BITS == 64 > +# if ! defined (_FILE_OFFSET_BITS) || _FILE_OFFSET_BITS != 64 > +# error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64" > +# elif __TIMESIZE == 32 > +# define __USE_TIME_BITS64 1 Is this correct? We only use __USE_TIME_BITS64 on machines where __TIMESIZE==32? On OpenRISC we have __TIMESIZE == 64, so __USE_TIME_BITS64 does not get defined. Hence the timex issue I mentioned earlier. Sorry, it's hard for me to understand what is the intent of some of these flags so I can't be sure where it's going wrong. > +# endif > +# elif _TIME_BITS == 32 > +# if __TIMESIZE > 32 > +# error "_TIME_BITS=32 is not compatible with __TIMESIZE > 32" > +# endif > +# else > +# error Invalid _TIME_BITS value (can only be 32 or 64-bit) > +# endif > +#endif > diff --git a/sysdeps/unix/sysv/linux/hppa/libanl.abilist b/sysdeps/unix/sysv/linux/hppa/libanl.abilist > index d9a5ed015d..ff719e7605 100644 -Stafford