Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)

From: Lukasz Majewski <lukma@denx.de>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Florian Weimer <fweimer@redhat.com>,
	Helmut Grohne <helmutg@debian.org>,
	GNU C Library <libc-alpha@sourceware.org>,
	Vineet Gupta <Vineet.Gupta1@synopsys.com>,
	Palmer Dabbelt <palmerdabbelt@google.com>,
	Zong Li <zongbox@gmail.com>,
	debian-arm@lists.debian.org,
	Alistair Francis <alistair.francis@wdc.com>,
	Adhemerval Zanella <adhemerval.zanella@linaro.org>,
	"Maciej W. Rozycki" <macro@wdc.com>,
	Alistair Francis <alistair23@gmail.com>,
	arcml <linux-snps-arc@lists.infradead.org>,
	Joseph Myers <joseph@codesourcery.com>
Subject: Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
Date: Mon, 24 Feb 2020 10:00:51 +0100	[thread overview]
Message-ID: <20200224100051.2511d797@jawa> (raw)
In-Reply-To: <CAK8P3a2n6fRm4C5Ywyk5ys92jSOAc5SwvBVZyFOY9=4rB2pyjw@mail.gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 3367 bytes --]

Hi Arnd,

> On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski <lukma@denx.de>
> wrote:
> 
> > [2] - https://github.com/lmajewski/y2038_glibc/commits/y2038_edge  
> 
> I tried packaging this into a .deb package for use with rebootstrap,
> but ran into a couple of test failures from glibc itself, when
> testing the i386 version while running on an older x86_64 kernel
> (4.15):

Thanks for testing. I do use 4.19 as the oldest kernel.

> 
> +---------------------------------------------------------------------+
> |     Encountered regressions that don't match expected failures.
> |
> +---------------------------------------------------------------------+
> FAIL: elf/check-localplt FAIL: nptl/tst-cancel19
> FAIL: rt/tst-mqueue2
> make: *** [debian/rules.d/build.mk:116:
> /home/arnd/glibc-2.31/stamp-dir/check_i386] Error 1
> 
> elf/check-localplt complains about the newly added symbols
> 
> Extra PLT reference: libc.so: __lutimes64
> Extra PLT reference: libc.so: __wait4_time64
> Extra PLT reference: libc.so: __setitimer64
> Extra PLT reference: libc.so: __utime64
> Extra PLT reference: libc.so: __timerfd_gettime64
> Extra PLT reference: libc.so: __clock_settime64
> Extra PLT reference: libc.so: __utimes64
> Extra PLT reference: libc.so: __gettimeofday64
> Extra PLT reference: libc.so: __clock_gettime64
> Extra PLT reference: libc.so: __futimesat64
> Extra PLT reference: libc.so: __clock_getres64
> Extra PLT reference: libc.so: __futimes64
> Extra PLT reference: libc.so: __futimens64
> Extra PLT reference: libc.so: __utimensat64
> Extra PLT reference: libc.so: __getrusage64
> Extra PLT reference: libc.so: __timespec_get64
> Extra PLT reference: libc.so: __getitimer64
> Extra PLT reference: libc.so: __ppoll64
> Extra PLT reference: libc.so: __timerfd_settime64
> Extra PLT reference: libc.so: __clock_nanosleep_time64
> Extra PLT reference: libc.so: __sched_rr_get_interval64
> Extra PLT reference: libc.so: __settimeofday64
> Extra PLT reference: librt.so: __timer_gettime64
> Extra PLT reference: librt.so: __mq_timedreceive_time64
> Extra PLT reference: librt.so: __mq_timedsend_time64
> Extra PLT reference: librt.so: __timer_settime64
> 

The above problems are somewhat expected. Those are redirected symbols,
which are exported as GLIBC_PRIVATE in several Versions files.

I do guess that we will have a consensus if we add those as a "normal"
exported symbols or keep them "private".

> which seems a bug in the test suite. The other two get a segfault
> that I have not debugged, but I guess this is likely a problem in your
> patches. Have you seen the same thing?

I only do run the full (including full test suite) glibc-many-build
(and my Y2038 tests) on the patches which I post to glibc-alpha.

The Y2038 changes I do test manually if they work as expected - but I
do not run yet the (full) test suites on it, as first _all_ glibc
functions needs to be converted before _TIME_BITS=64 is added.

The issue is probably with the redirection code. I will look on them
soon.

> 
>        Arnd

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

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc