> On May 26, 2021, at 8:14 PM, Mouse <[email protected]> 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

Reply via email to