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)

[Lukasz Majewski]

Hi Arnd,

> On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski <lukma@denx.de>
> wrote:
> > > On 2/14/20 2:39 PM, Alistair Francis wrote:  
> > > > On Tue, Feb 11, 2020 at 5:30 PM Joseph Myers  
> > > An the reason this all works on RISCV is that your kernel doesn't
> > > define __ARCH_WANT_STAT64 -> lacks __NR_statat64 and instead uses
> > > the statx call which does itemized copy and would work fine when
> > > copying from 32-bits time (in kernel) to 64-bits container in
> > > glibc. Is this is right understanding or am I missing something
> > > here.
> > >
> > > How do I build a latest RISCV 32-bit kernel + userland - do you
> > > have a buildroot branch somewhere that I can build / test with
> > > qemu ?  
> >
> > Maybe a bit off topic - there is such QEMU and Yocto/OE based test
> > sandbox for ARM32:
> >
> > https://github.com/lmajewski/meta-y2038
> >
> > (the README provides steps for setup).  
> 
> (continuing off-topic, with debian-arm and Helmut on Cc)
> 
> 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].

I also do have a 'warrior' based glibc branch [3], which is a bunch of
hacks to have glibc 2.29 Y2038 supporting. However, my policy now is
"upstream first" - so I would recommend adding any further glibc work
on top of [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).

I'm able to use runqemu to test the built glibc with kernel 4.19, 5.1
(for armv7).
This qemu run system can be used to run-test glibc tests on ARM32 with
test-wrapper='/opt/Y2038/glibc/src/scripts/cross-test-ssh.sh

Last but not least - OE/Yocto is used to provide BSP for embedded
systems, so I'm aligned with customers' needs.

However, I did not yet tried debian-rebootstrap. I will look if this
can be reused as well.

> 
> 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
- In-glibc test coverage when -D_TIME_BITS=64 is used. I do have
  some basic tests [4], but this may be not enough.

> aside from the exact ABI not being final yet?
> 
>         Arnd
> 
> [1] https://wiki.debian.org/HelmutGrohne/rebootstrap


Links:

[1] -
https://github.com/lmajewski/y2038_glibc/commit/4f72f695d1ac428fe945cd7d5e95770180d4a7c1
[2] - https://github.com/lmajewski/y2038_glibc/commits/y2038_edge
[3] -
https://github.com/lmajewski/y2038_glibc/commits/Y2038-2.29-glibc-warrior-01-08-2019

[4] - https://github.com/lmajewski/y2038-tests

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20200220/b892ce2b/attachment.sig>