Re: [Qemu-devel] [TestDays] s390x emulation error

[Alexander Graf]

On 12.11.2011, at 11:40, Stefan Weil <address@hidden> wrote:

> Am 12.11.2011 11:08, schrieb Andreas Färber:
>> Am 10.11.2011 12:29, schrieb Andreas Färber:
>> I found that the following main-loop change works around it for s390x
>> and rl78 but breaks x86_64 SeaBIOS boot. Paolo, any ideas?
>> 
>> diff --git a/main-loop.c b/main-loop.c
>> index 60e9748..2ab5023 100644
>> --- a/main-loop.c
>> +++ b/main-loop.c
>> @@ -460,7 +460,7 @@ int main_loop_wait(int nonblocking)
>> }
>> 
>> glib_select_poll(&rfds, &wfds, &xfds, (ret < 0));
>> - qemu_iohandler_poll(&rfds, &wfds, &xfds, ret);
>> + qemu_iohandler_poll(&rfds, &wfds, &xfds, (ret < 0));
>> #ifdef CONFIG_SLIRP
>> slirp_select_poll(&rfds, &wfds, &xfds, (ret < 0));
>> #endif
>> 
>> A deadlock between iothread and main?
>> 
>> Andreas
> 
> I just tried s390x on a 386 host (32 bit!) and got a different crash
> (modulo operation / division with 0.0).
> 
> Are 32 bit hosts supported?
> 
> Stefan
> 
> (gdb) r
> Starting program: 
> /home/stefan/src/qemu/qemu.org/qemu/bin/debug/386/s390x-softmmu/qemu-system-s390x
>  
> [Thread debugging using libthread_db enabled]
> [New Thread 0xae9d0b70 (LWP 6841)]
> 
> Program received signal SIGFPE, Arithmetic exception.
> [Switching to Thread 0xae9d0b70 (LWP 6841)]
> 0x08199f6b in __umoddi3 ()
> (gdb) i s
> #0  0x08199f6b in __umoddi3 ()
> #1  0x08168a48 in helper_dlg (r1=2, v2=0) at 
> /home/stefan/src/qemu/qemu.org/qemu/target-s390x/op_helper.c:369
> #2  0x00eb5a88 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> (gdb) up
> #1  0x08168a48 in helper_dlg (r1=2, v2=0) at 
> /home/stefan/src/qemu/qemu.org/qemu/target-s390x/op_helper.c:369
> 369            env->regs[r1] = env->regs[r1+1] % divisor;
> (gdb) l
> 364    {
> 365        uint64_t divisor = v2;
> 366
> 367        if (!env->regs[r1]) {
> 368            /* 64 -> 64/64 case */
> 369            env->regs[r1] = env->regs[r1+1] % divisor;
> 370            env->regs[r1+1] = env->regs[r1+1] / divisor;
> 371            return;
> 372        } else {
> 373
> (gdb) p divisor
> $1 = 0
> (gdb) p v2
> $2 = 0
> 

No, that's the expected result. I don't special-case division by 0 and my small 
virtio zipl boot rom triggers div by 0 when no hd is attached :)

Alex