Re: Unexpected behaviour when catching SIGFPE on FPU-less system

["Kevin D. Kissell" <kevink@paralogos.com>]

Shane McDonald wrote:
> Hi Kevin:
>
> On Mon, May 3, 2010 at 2:47 PM, Kevin D. Kissell <kevink@paralogos.com> wrote:
>   
>> Sorry about my previous message having escaped with no value added.
>>
>> I think you need to look at just what it is that your feclearexcept() does.
>>  From the strace information, it looks as if it may be that the FPU emulator
>> is erroneously throwing an exception in response to some manipulation of the
>> emulated FPU registers by feclearexcept(), so that it's taking a second FP
>> exception within the signal handler.  That's the simplest explanation for
>> the macroscopic behavior, anyway.
>>
>>         Regards,
>>
>>         Kevin K.
>>     
>
> Commenting out the feclearexcept() line gives the same result:
>
>      old_mmap(NULL, 65536, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ace9000
>      write(1, "About to try calculation\n"..., 25About to try calculation
>      ) = 25
>      --- SIGFPE (Floating point exception) @ 0 (0) ---
>      --- SIGFPE (Floating point exception) @ 0 (0) ---
>      +++ killed by SIGFPE +++
>
> So, it must not be the feclearexcept() causing the problem.
>   
Well, that nested floating point exception must be coming from 
*somewhere*.  If it's not library code being betrayed by the emulator, 
perhaps some kernel-mode code is being invoked which is carelessly 
assuming the existence of a hardware FPU and throwing us back into the 
exception handler. If it was me, at this point, I'd turn on some kind of 
logging of FP exception PCs to see where that second one is coming from.

There was a time when I had the necessary equipment on my desk to hunt 
this down and kill it, out of a lingering sense of responsibility for 
having bolted that FPE into the kernel way back when.  I no longer have 
that setup, so I'm free to speculate. ;o)

          Regards,

          Kevin K.