Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation

[Dann Frazier]

On Mon, Feb 17, 2014 at 6:40 AM, Alex Bennée <address@hidden> wrote:
> Hi,

Thanks to all involved for your work here!

> After a solid few months of work the QEMU master branch [1] has now reached
> instruction feature parity with the suse-1.6 [6] tree that a lot of people
> have been using to build various aarch64 binaries. In addition to the
> SUSE work we have fixed numerous edge cases and finished off classes of
> instructions. All instructions have been verified with Peter's RISU
> random instruction testing tool. I have also built and run many
> packages as well as built gcc and passed most of the aarch64 specific tests.
>
> I've tested against the following aarch64 rootfs:
>     * SUSE [2]
>     * Debian [3]
>     * Ubuntu Saucy [4]

fyi, I've been doing my testing with Ubuntu Trusty.

> In my tree the remaining insns that the GCC aarch64 tests need to
> implement are:
>     FRECPE
>     FRECPX
>     CLS (2 misc variant)
>     CLZ (2 misc variant)
>     FSQRT
>     FRINTZ
>     FCVTZS
>
> Which I'm currently working though now. However for most build tasks I
> expect the instructions in master [1] will be enough.
>
> If you want the latest instructions working their way to mainline you
> are free to use my tree [5] which currently has:
>
> * Additional NEON/SIMD instructions
> * sendmsg syscall
> * Improved helper scripts for setting up binfmt_misc
> * The ability to set QEMU_LOG_FILENAME to /path/to/something-%d.log
>   - this is useful when tests are failing N-levels deep as %d is
>     replaced with the pid
>
> Feedback I'm interested in
> ==========================
>
> * Any instruction failure (please include the log line with the
>   unsupported message)
> * Any aarch64 specific failures (i.e. not generic QEMU threading flakeiness).

I'm not sure if this qualifies as generic QEMU threading flakiness or not. I've
found a couple conditions that causes master to core dump fairly
reliably, while the aarch64-1.6 branch seems to consistently work
fine.

 1) dh_fixperms is a script that commonly runs at the end of a package build.
     Its basically doing a `find | xargs chmod`.
 2) debootstrap --second-stage
     This is used to configure an arm64 chroot that was built using
     debootstrap on a non-native host. It is basically invoking a bunch of
     shell scripts (postinst, etc). When it blows up, the stack consistently
     looks like this:

Core was generated by `/usr/bin/qemu-aarch64-static /bin/sh -e
/debootstrap/debootstrap --second-stage'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000060058e55 in memcpy (__len=8, __src=0x7fff62ae34e0,
__dest=0x400082c330) at
/usr/include/x86_64-linux-gnu/bits/string3.h:51
51  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
(gdb) bt
#0  0x0000000060058e55 in memcpy (__len=8, __src=0x7fff62ae34e0,
__dest=0x400082c330) at
/usr/include/x86_64-linux-gnu/bits/string3.h:51
#1  stq_p (v=274886476624, ptr=0x400082c330) at
/mnt/qemu.upstream/include/qemu/bswap.h:280
#2  stq_le_p (v=274886476624, ptr=0x400082c330) at
/mnt/qemu.upstream/include/qemu/bswap.h:315
#3  target_setup_sigframe (set=0x7fff62ae3530, env=0x62d9c678,
sf=0x400082b0d0) at /mnt/qemu.upstream/linux-user/signal.c:1167
#4  target_setup_frame (address@hidden, address@hidden
<sigact_table+512>, address@hidden, address@hidden,
address@hidden)
    at /mnt/qemu.upstream/linux-user/signal.c:1286
#5  0x0000000060059f46 in setup_frame (env=0x62d9c678,
set=0x7fff62ae3530, ka=0x604ec1e0 <sigact_table+512>, sig=17) at
/mnt/qemu.upstream/linux-user/signal.c:1322
#6  process_pending_signals (address@hidden) at
/mnt/qemu.upstream/linux-user/signal.c:5747
#7  0x0000000060056e60 in cpu_loop (address@hidden) at
/mnt/qemu.upstream/linux-user/main.c:1082
#8  0x0000000060005079 in main (argc=<optimized out>, argv=<optimized
out>, envp=<optimized out>) at
/mnt/qemu.upstream/linux-user/main.c:4374

There are some pretty large differences between these trees with
respect to signal syscalls - is that the likely culprit?

 -dann



> If you need to catch me in real time I'm available on #qemu (stsquad)
> and #linaro-virtualization (ajb-linaro).
>
> Many thanks to the SUSE guys for getting the aarch64 train rolling. I
> hope your happy with the final result ;-)
>
> Cheers,
>
> --
> Alex Bennée
> QEMU/KVM Hacker for Linaro
>
> [1] git://git.qemu.org/qemu.git master
> [2] 
> http://download.opensuse.org/ports/aarch64/distribution/13.1/appliances/openSUSE-13.1-ARM-JeOS.aarch64-rootfs.aarch64-1.12.1-Build32.1.tbz
> [3] 
> http://people.debian.org/~wookey/bootstrap/rootfs/debian-unstable-arm64.tar.gz
> [4] http://people.debian.org/~wookey/bootstrap/rootfs/saucy-arm64.tar.gz
> [5] https://github.com/stsquad/qemu/tree/ajb-a64-working
> [6] https://github.com/susematz/qemu/tree/aarch64-1.6
>