On Tue, Nov 3, 2020 at 3:03 AM Lukasz Majewski <lu...@denx.de> wrote: > > Dear Qemu Community,
Hey Lukasz, + QEMU Dev Mailing list + Laurent > > I would like to ask you for some advice regarding the usage of > arm-linux-user/qemu-arm user space program simulation. > > Background: > ----------- > > I'm looking for a way to efficiently test y2038 in-glibc solution for > 32 bit architectures (e.g. ARM). > > For now I do use qemu-system-arm (part of Yocto/OE), which I'm using to > run Linux kernel 5.1, glibc under test and Y2038 tests. It works [1]. > > Problem: > -------- > > I would like to test cross-compiled tests (which are built from glibc > sources) without the need to run the emulated system with > qemu-system-arm. > > I've come across the "QEMU user mode", which would execute the > cross-compiled test (with already cross-compiled glibc via -L switch) > and just return exit status code. This sounds appealing. As another advantage it is much, much faster at running the glibc tests. > > As fair as I've read - QEMU user mode emulates ARM syscalls. > > During test execution (single qemu user mode process) I would need to > adjust date with clock_settime64 syscall and then execute other > syscalls if needed. > > > Please correct me if I'm wrong: > - It looks like qemu-arm doesn't have switch which would allow it to > set time offset (to e.g. year 2039 - something similar to > qemu-system-arm -rtc=). > > - As of 5.1 qemu version there is no support for syscalls supporting 64 > bit time on 32 bit architectures (e.g. clock_settime64 and friends > from [2]). There is some support in the current master, for example __NR_futex_time64 is supported. I started to add some support for RV32 once it was merged into glibc. > > For my example program [3] statically build for testing (it works with > qemu-system-arm): > > ~/work/qemu-arm-tests-program$ > ../qemu-5.1.0-arm/arm-linux-user/qemu-arm -L > ~/work/yocto/y2038/build/tmp/armv7at2hf-neon-poky-linux-gnueabi/y2038-glibc/2.30+git999-r0/image/opt > -strace ./cst > > 17746 brk(NULL) = 0x00074000 > 17746 brk(0x000748a8) = 0x000748a8 > 17746 uname(0x40800370) = 0 > 17746 readlink("/proc/self/exe",0x407ff488,4096) = 43 > 17746 brk(0x000958a8) = 0x000958a8 > 17746 brk(0x00096000) = 0x00096000 > 17746 mprotect(0x00070000,8192,PROT_READ) = 0 > 17746statx(1,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x407ffd70) > = 0 > 17746 Unknown syscall 404 --> is the syscall number of clock_settime64 clock_settime64 is supported in master QEMU. > > 17746 dup(2) = 3 > 17746 fcntl64(3,F_GETFL) = 2 > 17746statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x407ff8e8) > = 0 ERR > > Questions: > ---------- > > 1. Is there any plan to add support for emulating syscalls supporting > 64 bit time on 32 bit architectures [2]? I would like to have RV32 supported, but it's a low priority for me. I expect it's something that will eventually happen though. > > 2. Provide QEMU user space switch to adjust its time (i.e. add some > offset to in-fly emulated time syscalls - like clock_settime64) when it > is started? That I'm not sure about. I assume just running date/clock_settime64 from a script wouldn't work with the glibc test framework? Alistair > > > Thanks in advance for your help and reply. > > > Links: > [1] - https://github.com/lmajewski/meta-y2038/ > [2] - > https://elixir.bootlin.com/linux/latest/source/arch/arm/tools/syscall.tbl#L419 > > [3]: > Example program: > cat <<- EOF >> clock_settime_test.c > #include <stdio.h> > #include <time.h> > > int main (int argc, char **argv) > { > struct timespec tv; > int ret; > > tv.tv_sec = 0x7FFFFFFF; > tv.tv_sec += 61; > tv.tv_nsec = 0; > > printf("clock_settime test program: "); > ret = clock_settime(CLOCK_REALTIME, &tv); > if (!ret) > printf("OK\n"); > else > perror("ERR\n"); > > return 0; > } > EOF > > Build the test program: > gcc -Wall -ggdb -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 -I/opt/include > -I/opt/usr/include -L/opt/usr/lib \ -Wl,-rpath=/opt/lib > -Wl,--dynamic-linker=/opt/lib/ld-linux.so.2 clock_settime_test.c -o cst > -static > > > > 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: lu...@denx.de