Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions

[Richard Henderson <rth@twiddle.net>]

On 07/08/2014 01:05 AM, Peter Maydell wrote:
> On 8 July 2014 08:13, Al Viro <viro@zeniv.linux.org.uk> wrote:
>> Actually, that's badly worded; what codepath ends up setting si_code on
>> e.g. fp addition overflows?  In system mode it's done by completion code
>> in the kernel, but AFAICS in user mode there are only two places where it
>> might happen - one is gentrap handling and another - osf_setsysinfo(2)
>> emulation for TARGET_SSI_IEEE_FP_CONTROL.  What I don't understand is how
>> do we get from float_raise(&FP_STATUS, float_flag_overflow) in fpu/softfloat.c
>> to either of those.
>>
>> IOW, suppose I do
>>         x = DBL_MAX;
>>         feenableexcept(FE_ALL_EXCEPT);
>>         x *= x;
>> I understand how I'll get SIGFPE, but what will set correct si_code in
>> siginfo I'll see in the hanler?
> 
> The code we have currently may well be buggy, but the correct
> place to set si_code is (as Richard says) the Alpha cpu_loop() in
> linux-user/main.c, which has access to the trap type that just
> caused us to stop executing code, plus the CPUState, which
> should be enough information to set si_code correctly. In
> particular the GENTRAP case seems to be setting a variety
> of different si_code values for SIGFPE.

The gentrap case is a red-herring.

The case you're looking for is EXC_ARITH.  The path is from

    arith_excp
      dynamic_excp
        cpu_loop_exit
          longjmp
  cpu_exec
cpu_loop

It's also true that we don't install the correct si_code there, but we could.
Mostly the gcc/glibc test cases really only care that SIGFPE gets raised, not
what the codes are, so I haven't bothered.


r~