qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] signed division overflow workaround


From: Max Filippov
Subject: Re: [Qemu-devel] signed division overflow workaround
Date: Fri, 12 Aug 2011 14:41:43 +0400

>> Hello.
>>
>>> +            case 13: /*QUOSi*/
>>> +                tcg_gen_div_i32(cpu_R[RRR_R], cpu_R[RRR_S], cpu_R[RRR_T]);
>>> +                break;
>>
>> I'm currently developing test suite for xtensa port and found that
>> with this implementation of QUOS (signed 32-bit division) guest that
>> divide 0x80000000 by -1 crashes qemu with 'floating point exception'
>> on x86_64 host.
>
> Yes. See tcg/README, which says:
> # Undefined behavior if division by zero or overflow.
>
> This is basically because the behaviour varies rather from architecture
> to architecture so (a) it would be a pain to implement consistent
> handling in the tcg backends and (b) all the front-ends would probably
> still need special case handling to give the results the guest arch
> requires. (What is xtensa's behaviour for div by zero and the overflow
> case ?)

div by zero -> exception, has a special case handler already;
overflow -> result == 0x80000000, no other side effects.

>> I guess that this is a known issue, at least target-arm has a special
>> case to handle this. Is there a better way to handle this issue, or
>> special-casing is the only option?
>
> I wouldn't do what target-arm does: it goes out to a helper function,
> probably because that code predates the addition of brcond to TCG.
> PPC and MIPS are probably better candidates to crib from, as they
> both do the special-case checks inline.

I meant generally specialcasing vs hw exceptions/whatever.
ARM just have it explicitly coded. For xtensa I'd do it inline too.

BTW, I see that target-microblaze has the same issue.

-- 
Thanks.
-- Max



reply via email to

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