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

[Lukasz Majewski <lukma@denx.de>]

[-- Attachment #1: Type: text/plain, Size: 6203 bytes --]

Hi Alistair,

> On Tue, Nov 3, 2020 at 3:03 AM Lukasz Majewski <lukma@denx.de> wrote:
> >
> > Dear Qemu Community,  
> 
> Hey Lukasz,
> 
> + QEMU Dev Mailing list
> + Laurent
> 

Thanks for reaching more people.

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

+1

> >
> > 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've just looked into v5.1.0 stable release. I will double check this
with -master branch.

> 
> I started to add some support for RV32 once it was merged into glibc.

Ok.

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

I will double check it - thanks for pointing this out.

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

Having syscalls supporting 64 bit time on 32 bit machines indicated in
[2] would be a very welcome for glibc testing.

> I
> expect it's something that will eventually happen though.

Ok.

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

For me it would be enough to have:

qemu-arm -rtc="2039-01-01" -L... ./ctx
So the emulated "time" would be after 32 bit time_t overflow when
QEMU user space emulation process starts (as long as it doesn't touch
the host machine time).


Another option (workaround) would be to run clock_settime64() with time
set to year 2038+ on the beginning of each glibc test. It shall work as
long as we don't change host time (and all time changes would stay in
the qemu user mode process).

> I assume just running date/clock_settime64
> from a script wouldn't work with the glibc test framework?

Could you elaborate on this use case/scenario? Do you have some
examples to share?

> 
> 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:
> > lukma@denx.de  




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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]