On Mon, Feb 17, 2014 at 6:40 AM, Alex Bennée <alex.ben...@linaro.org> 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 (usig=usig@entry=17, ka=ka@entry=0x604ec1e0
<sigact_table+512>, info=info@entry=0x0, set=set@entry=0x7fff62ae3530,
env=env@entry=0x62d9c678)
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 (cpu_env=cpu_env@entry=0x62d9c678) at
/mnt/qemu.upstream/linux-user/signal.c:5747
#7 0x0000000060056e60 in cpu_loop (env=env@entry=0x62d9c678) 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
>
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
