Hi Arnd, > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski <lukma@xxxxxxx> > 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@xxxxxxx
Attachment:
pgplNafW8yyWo.pgp
Description: OpenPGP digital signature
_______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
