On Mon, 5 Mar 2001, Chris Gilbert wrote:

> On Monday 05 March 2001  9:47 pm, Ben Harris wrote:
> > There seems to be some disagreement between arm26 and arm32 over the value
> > of the tf_pc field in a trapframe, which contains the value of the
> > user program counter after an exception.
> >
> > In arm26, I deliberately made sure that it was always the address of the
> > faulting instruction, so as to avoid confusing myself.  In arm32, it's the
> > address of the faulting instruction for address and data aborts, and the
> > address of the next instruction for SWIs and undefined instructions.
> 
> Sounds like it's how the value is to be used, eg after a SWI you branch back, 
> if you emulate the undef instr then you branch back, if you get an address of 
> data abort you want to know where?

Yes.  It's setting tf_pc to the most likely value to be needed on return,
which has some sense behind it.

> So we certainly manipulate the values at some point.  I'd prefer that the SWI 
> stays as is, seems little point in adding 4 just to take it away later. 
> (chris in the we'll save 1 instr if it kills us 8)

Heh.  One instruction really isn't much over the whole of syscall().  We
have to do the subtraction anyway to get at the instruction to read the
system call number.

> I'm not sure either way, however part of me sees the current logic as being 
> this is how we use this value so we'll have it make sense, however it could 
> make sense to have it as you say as well :)

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.

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