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)
- To: Arnd Bergmann <arnd@arndb.de>
- Cc: Lukasz Majewski <lukma@denx.de>, Vineet Gupta <Vineet.Gupta1@synopsys.com>, Joseph Myers <joseph@codesourcery.com>, Florian Weimer <fweimer@redhat.com>, GNU C Library <libc-alpha@sourceware.org>, Palmer Dabbelt <palmerdabbelt@google.com>, Zong Li <zongbox@gmail.com>, Alistair Francis <alistair.francis@wdc.com>, Adhemerval Zanella <adhemerval.zanella@linaro.org>, "Maciej W. Rozycki" <macro@wdc.com>, arcml <linux-snps-arc@lists.infradead.org>, debian-arm@lists.debian.org, Helmut Grohne <helmutg@debian.org>
- 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)
- From: Alistair Francis <alistair23@gmail.com>
- Date: Fri, 21 Feb 2020 11:56:38 -0800
- Message-id: <[🔎] CAKmqyKMKZMEtzGNTz2x0VDGyU8YHp0rLFQNEJ+XU6r1BYAOExg@mail.gmail.com>
- In-reply-to: <[🔎] CAK8P3a1nte0nGMw8_aeS__iJsTvsSGYYuKivAYBdiGH-GjVGew@mail.gmail.com>
- References: <cover.1578824547.git.alistair.francis@wdc.com> <4e95f95966d8d7c6a8339160dc62d81c1f6a1bfb.1578824547.git.alistair.francis@wdc.com> <00574bfb-981a-3a1c-cbdf-b2fee4eddc32@gmail.com> <CAKmqyKMyf2psPp+-EHoidvbPbSXv0=dP26GjVQnT5BUriLc1gA@mail.gmail.com> <alpine.DEB.2.21.2002120123230.3988@digraph.polyomino.org.uk> <CAKmqyKOgFRfMOws_-48GqMnuS3ygmN9A4DzLg6UtEjRXVoM82A@mail.gmail.com> <8a9784b3-fc52-adc3-4595-33142b059388@synopsys.com> <20200220001136.2f14236e@jawa> <[🔎] CAK8P3a1b73K+RjfHONWLy_dFUucXxwd+0jTnHmkf6YqwRjit4w@mail.gmail.com> <[🔎] 20200220103716.2f526933@jawa> <[🔎] CAK8P3a1nte0nGMw8_aeS__iJsTvsSGYYuKivAYBdiGH-GjVGew@mail.gmail.com>
On Thu, Feb 20, 2020 at 4:37 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski <lukma@denx.de> wrote:
> > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski <lukma@denx.de>
> > >
> > > Would it be possible to take a snapshot of your glibc tree
> >
> > The description of the status of Y2038 supporting glibc on ARM 32 can
> > be found here [1].
> >
> > The most recent patches for Y2038 supporting glibc can be always found
> > in the 'y2038_edge' branch [2].
>
> Ok.
>
> > > and start testing this out with debian-rebootstrap [1]?
> >
> > I've been using OE/Yocto for testing as it allows building glibc
> > sources for x86_64, x86, x86-x32, arm32 (probably also for ppc32 and
> > mips - but not tested).
> >...
> > However, I did not yet tried debian-rebootstrap. I will look if this
> > can be reused as well.
>
> The reason I'm asking about debian-rebootstrap is less about testing
> glibc itself than about testing the rest of user space to figure out better
> what needs to be done when rebuilding with _TIME_BITS=64, and to
> start fixing more upstream packages, with the hope of having enough
> of it done in time for the Debian 11 release.
We have started to do that for RISC-V 32-bit. I have fixed up some
things in Busybox and OpenSSL to improve 64-bit time_t support on
32-bit archs. In meta-riscv (and OpenEmbedded layer) we are tracking
issues: https://github.com/riscv/meta-riscv/issues/202
Right now it's all compile focused though, not so much run time testing.
Alistair
>
> > > Are there any glibc issues that prevent it from working correctly,
> >
> > I think that the glibc wrappers for most important syscalls are now
> > converted.
> >
> > What is missing:
> >
> > - NTPL (threads)
> > - stat
>
> Do you mean that code using these will fail to work correctly with
> -D_TIME_BITS=64 at the moment, or that the interfaces are there
> but they are not y2038 safe? Without pthreads or stat, we probably
> wouldn't get too far in rebootstrap, but if the interfaces are there
> and mostly work, then we don't need to rely on them being
> y2038-safe just yet. An obvious next step would be to run the
> resulting code with the RTC set 20 years ahead, and that requires
> it all to work.
>
> > - In-glibc test coverage when -D_TIME_BITS=64 is used. I do have
> > some basic tests [4], but this may be not enough.
>
> This is probably something where debian-rebootstrap could help,
> as building and testing more user space packages will excercise
> additional code paths in glibc as well. There is also some work
> in Linaro to ensure that LTP tests the low-level syscall interfaces
> in both the time32 and time64 variants.
>
> Arnd
Reply to: