On Tue, 6 Mar 2001, Richard Earnshaw wrote:

> 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.

Ugh.  I don't see how that's any better than my arrangement.

> 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.

Yeah, that'll be fun.  Hmm.  That seems like an argument for keeping tf_pc
being the address of the faulting instruction, since it'll need fixing up
anyway.

> 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).

Erm, can any of them cause the SWI handler to be entered?  This code is
part of the SWI handler, and barring processor bugs (one of which is what
the code guards against), should only be executed on SWI instructions.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>