[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] target-s390x: assertion failure in op_risbg

From: Thomas Huth
Subject: Re: [Qemu-devel] target-s390x: assertion failure in op_risbg
Date: Tue, 7 Nov 2017 13:00:14 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

On 07.11.2017 12:41, Peter Maydell wrote:
> This is from https://bugs.launchpad.net/qemu/+bug/1701798, but
> that's quite a large thing, so here's the s390 specific part.
> On an ubuntu xenial install:
> $ apt install g++-5-s390x-linux-gnu
> $ cat hello.c
> #include <stdio.h>
> int main(void) {
>     printf("hello world\n");
>     return 0;
> }
> $ s390x-linux-gnu-gcc-5 -O hello.c -o hello.s390x
> $ QEMU_LD_PREFIX=/usr/s390x-linux-gnu/ gdb --args
> ~/linaro/qemu-from-laptop/qemu/build/all-linux-static/s390x-linux-user/qemu-s390x
> ./hello.s390x
> [...]
> (gdb) r
> [...]
> Thread 1 "qemu-s390x" received signal SIGABRT, Aborted.
> 0x0000000060215018 in raise ()
> (gdb) bt
> #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)
> This is because in op_risbg() we abort() if s->fields->op2 is not
> one of 0x55, 0x5d, 0x51. In this case it is 0x59. I don't know enough
> s390 to know what this might be, but we shouldn't really abort()
> inside QEMU for unimplemented guest insns.

If I've got the spec right, the 0x59 here means that it is a "new"
instruction called RISBGN which we do not support in QEMU yet. Instead
of calling abort(), the correct behavior for unsupported instructions
here is to generate a "operation" exception. Or even better: Implement
the instruction. If I've got the spec right, it's doing the same as
RISBG (with subcode 0x55), but just does not set the condition code at
the end, so this should be quite easy to implement?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]