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 Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski <lukma@xxxxxxx> wrote:
> > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski <lukma@xxxxxxx>
> >
> > 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].


> > 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.

> > 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.


linux-snps-arc mailing list

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux