Re: Expected behavior when returning from a SIGFPE handler

[Jason Thorpe <thorpej%me.com@localhost>]

> On May 26, 2021, at 8:14 PM, Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
> 
>> But the x86_64 code appears to return to the same instruction, banging its h$
> 
>> It's my belief that the alpha behavior is more desirable.
> 
>> Please, discuss.
> 
> I could argue that either way.
> 
> In some cases, you want to re-execute the instruction.  A simple
> example is "FPU disabled" on architectures that have such a notion, eg
> for lazy FPU switching.

We’re not talking about lazy FPU switching here… we’re talking about performing an FP operation that causes an exception per the IEEE 754 rules. The traps generated in these two situations are easily distinguishable, and user-space code has no visibility into lazy FPU switching traps (modulo the sorts of speculative execution information leaks that modern CPUs are vulnerable to).

This is all about what to do AFTER the user-specified signal handler has been called, and it returns to normal program flow via the sigreturn path.

> In some cases, you don't want to.  An example might be soft-float, or
> partial soft-float (such as, emulation of cases the hardware doesn't
> handle).

As I mentioned, on the Alpha, the PALcode pushes a trap frame with the PC pointing at least one instruction *after* the one that triggered the arithmetic exception (on EV6, it’s the instruction immediately following, on pre-EV6, you have to go looking backwards in the instruction stream for it).

> On architectures like SPARC or, I think - you'd know better than I -
> Alpha, where there are very few possible instruction sizes, sometimes
> as few as just one, advancing past the instruction in the trap handler
> is easy even if you have to do it in software.  On others, like the
> VAX, it's a right pain to do in software.  On the latter sort, ideally,
> the hardware would give you both the PC to use to re-execute the
> instruction and the PC to use to skip the instruction, letting the trap
> handler choose, but I'm not aware of any architecture that does that.
> (The closest I'm aware of is, ironically, the SPARC, on which advancing
> past an instruction in software is about as simple as it gets - but it
> has both PC and next-PC in hardware, though admittedly for other
> reasons.)
> 
> I see no clear single right answer here.

I’m not particularly concerned about VAX in this case; it doesn’t have IEEE 754 floating point, so all bets are off :-)

-- thorpej