> My logic (as I remember it) was that the trap handler's job is to try to
> execute the instruction (the hardware having tried and failed).  As such,
> it should start with the registers in the state before the instruction is
> executed.  If it executes the instruction itself (e.g. a SWI or FP
> insn) _it_ should be incrementing the PC.
> 
> Also, it just seems strange to me to be doing things like
> ReadWord(frame->tf_pc - INSN_SIZE) to get the current instruction.
> 
> In any case, I suspect the right way to go may ultimately be decided by
> how signal handling is supposed to work, for which I suspect I need to
> consult tech-kern.

Hm, maybe we should clean this all up by creating two variables: 
tf_fault_addr and tf_return_addr.  tf_fault_addr will *always* point at 
the faulting instruction;  tf_return_addr will point to the most likely 
continuation address.

The code in the trap handler is going to need extensive work to support 
thumb; for example, we can't just subtract INSN_SIZE any more since the 
size varies depending on whether the faulting instruction was Thumb or 
not.  Similar issues apply to calculating the return address.

Oh, and this code (in syscall.c) is just plain wrong on ARMv5:

    if ((ReadWord(frame->tf_pc - INSN_SIZE) & 0x0f000000) != 0x0f000000) {

There are valid instructions in the NV space now (though at this time, I 
don't think any of them can fault).

R.