Comment 6 for bug 1701798

I just tested with powerpc and current head-of-git QEMU and it works:

e104462:xenial:bug-1701798$ cat hello.c
#include <stdio.h>
int main(void) {
    printf("hello world\n");
    return 0;
}
e104462:xenial:bug-1701798$ powerpc-linux-gnu-gcc-5 -O hello.c -o hello.powerpc
e104462:xenial:bug-1701798$ QEMU_LD_PREFIX=/usr/powerpc-linux-gnu ~/linaro/qemu-from-laptop/qemu/build/all-linux-static/ppc-linux-user/qemu-ppc ./hello.powerpc
hello world

Similarly mips, sparc64, powerpc64, hppa, mips64 are fine.

m68k is known to be not working for real m68k currently (it's mostly a coldfire target), so not surprising that that doesn't work.

s390x still crashes:
qemu-s390x: /home/petmay01/linaro/qemu-from-laptop/qemu/accel/tcg/translate-all.c:189: tb_lock: Assertion `!have_tb_lock' failed.

So either we've fixed a bug here, or the problem is in your environment.

For s390, it looks like the guest is trying to use an insn we don't implement:
#0 0x0000000060215018 in raise ()
#1 0x000000006021573a in abort ()
#2 0x0000000060079a96 in op_risbg (s=0x7fffffffda10, o=0x7fffffffd950)
    at /home/petmay01/linaro/qemu-from-laptop/qemu/target/s390x/translate.c:3450
#3 0x0000000060082c8b in translate_one (env=0x627f0350, s=0x7fffffffda10)
    at /home/petmay01/linaro/qemu-from-laptop/qemu/target/s390x/translate.c:5824
#4 0x0000000060082f3f in gen_intermediate_code (cs=0x627e80b0,
    tb=0x60794d40 <static_code_gen_buffer+56064>)
    at /home/petmay01/linaro/qemu-from-laptop/qemu/target/s390x/translate.c:5925
#5 0x00000000600369aa in tb_gen_code (cpu=0x627e80b0, pc=274886359240,
    cs_base=0, flags=3, cflags=0)
    at /home/petmay01/linaro/qemu-from-laptop/qemu/accel/tcg/translate-all.c:1286
#6 0x00000000600343ff in tb_find (cpu=0x627e80b0,
    last_tb=0x60794c00 <static_code_gen_buffer+55744>, tb_exit=0, cf_mask=0)
    at /home/petmay01/linaro/qemu-from-laptop/qemu/accel/tcg/cpu-exec.c:402
#7 0x0000000060034b36 in cpu_exec (cpu=0x627e80b0)
    at /home/petmay01/linaro/qemu-from-laptop/qemu/accel/tcg/cpu-exec.c:722
#8 0x000000006003ac78 in cpu_loop (env=0x627f0350)
    at /home/petmay01/linaro/qemu-from-laptop/qemu/linux-user/main.c:3255
---Type <return> to continue, or q <return> to quit---
#9 0x000000006003c68c in main (argc=2, argv=0x7fffffffe458, envp=0x7fffffffe470)
    at /home/petmay01/linaro/qemu-from-laptop/qemu/linux-user/main.c:4882

where the abort is in op_risbg() because s->fields->op2 is 0x59, which we don't handle.

We then fail to correctly report that abort(), because linux-user has never been very good with reporting signals caused by QEMU itself -- it assumes signals including SIGABRT are due to the guest code and tries to deliver them as guest signals, usually tripping itself up in the process. We then run into the bug described in https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg01506.html which is why we get the have_tb_lock assertion.