On Mar 16, 2005, at 11:52 AM, Richard Earnshaw wrote:

> 1) Do other cores have imprecise faults? (By 'fault' I mean to raise an
> exception or to do software emulation of the operation because the 
> values
> in question can't be determined by the hardware.  By imprecise I mean 
> that
> the current PC value does not point to the instruction and that it 
> isn't a
> simple permutation of that value to get the address of the faulting
> instruction.)  I think the answer to this one must be 'yes', but I'd 
> like
> to see confirmation from someone more familiar with the other
> architectures.

The alpha has imprecise FP traps.  There is this whole notion of the 
"trap shadow".  Here is the comment that describes what has to happen 
(from alpha_fp_complete()):

/*
  * At this point we are somwhere in the trap shadow of one or more 
instruc-
  * tions that have trapped with software completion specified.  We have 
a mask
  * of the registers written by trapping instructions.
  *
  * Now step backwards through the trap shadow, clearing bits in the
  * destination write mask until the trigger instruction is found, and
  * interpret this one instruction in SW. If a SIGFPE is not required, 
back up
  * the PC until just after this instruction and restart. This will 
execute all
  * trap shadow instructions between the trigger pc and the trap pc 
twice.
  *
  * If a SIGFPE is generated from the OSF1 emulation,  back up one more
  * instruction to the trigger pc itself. Native binaries don't because 
it
  * is non-portable and completely defeats the intended purpose of IEEE
  * traps -- for example, to count the number of exponent wraps for a 
later
  * correction.
  */

> 2) If so, can the PC value of the faulting instruction always be
> recovered?  If not, what information is passed to a SIGFPE handler?  On
> the VFP the instruction opcode is known, but not the address of the
> fault-raising instruction.  I guess it would be possible to write the
> opcode to memory somewhere and point the siginfo frame at that; but is
> there a standard procedure for doing this?

In the Alpha code, if the trigger insn cannot be found, then SIGFPE is 
sent to the process.

> 3) What happens if there is a pending fault and the process gets 
> stopped
> in GDB before we can handle it?  Do we just lie to the user and pretend
> the floating point state is correct? or do we somehow try to stabilize 
> the
> register values before we pass them to GDB?  If the latter, what if 
> there
> are multiple outstanding operations and one (or more) would need to 
> raise
> SIGFPE?

The Alpha code doesn't compensate for this, as far as I can tell (I 
didn't write that code, thank goodness :-)

Ross Harvey could give you more information about how the Alpha FP trap 
stuff works.

-- thorpej