On 07/08/2014 01:05 AM, Peter Maydell wrote:
> On 8 July 2014 08:13, Al Viro <v...@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~
