Subject: Re: tf_pc value
To: Richard.Earnshaw@arm.com, Richard Earnshaw <rearnsha@arm.com>
From: Chris Gilbert <chris@paradox.demon.co.uk>
List: port-arm32
Date: 03/06/2001 10:07:31
On Tuesday 06 March 2001  9:50 am, Richard Earnshaw wrote:
> > 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.

I think I saw in the ARM ARM something about working out if it's a thumb or 
not.  However I'd think that a lot of the asm in the kernel would need 
revisiting for a thumb port.

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

That code is only of relevance to broken arm7's, and if arm have put us in 
the awkward situation of having instr's in the NV space, then something was 
bound to give when trying to support all their processors (broken or not).

I suspect this won't be a problem as long as you can't get the same hardware 
with either an arm7 or an archv5 chip in, as it can be #ifdef'd out if you're 
using an archv5 or later...

Chris