Re: [QEMU] Question regarding user mode support for ARM syscalls

[Alex Bennée]

Lukasz Majewski <lukma@denx.de> writes:

> Dear Qemu Community,
>
> 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 fair as I've read - QEMU user mode emulates ARM syscalls.

It's not strictly an emulation - it is more of a guided pass-through.
QEMU may tweak details like re-arranging structures or handling
byte-swapping but ultimately the syscall is passed down to the host
system.

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

This will set the time on your host system.

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

No - most of the command line switches pertain to memory layout and how
libraries are searched for. The details of the results of system calls
are very much left up to the host.

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

Hmm since 5bcb4986384e02669418a411cac10377cf48e698 the syscall table has
had mappings for all of those:

# 402 is unused
403     common  clock_gettime64                 sys_clock_gettime
404     common  clock_settime64                 sys_clock_settime
405     common  clock_adjtime64                 sys_clock_adjtime

>
> 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
>
> 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]?

It's certainly a bug if it's not working for you.

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

Unlikely - but you could carry a local patch for your own purposes.

-- 
Alex Bennée