On Thu, Feb 20, 2020 at 4:37 AM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > 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]. > > 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 _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
