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. thanks -- PMM
