Re: Register fudging (CRISv32)

[Daniel Jacobowitz <drow@false.org>]

On Fri, Sep 03, 2004 at 04:30:39PM +0200, Orjan Friberg wrote:
> Daniel Jacobowitz wrote:
> >
> 
> Daniel, thanks for you answers.
> 
> >Up to you.  I think doing it in the kernel stub and kernel ptrace
> >support is a better strategy, esp. if you have additional information
> >confirming that a breakpoint was hit.
> 
> In the kernel I know for sure it was a breakpoint (or, more 
> specifically, a certain break instruction was executed, which is how 
> ordinary breakpoints are implemented).
> 
> >There's arguments both ways for this.  For instance, I think it would
> >be reasonable to do this in the kernel.
> 
> Except for the fact that the "PC" doesn't exist in the kernel - it's a 
> made up register, which is set either from the exception return pointer 
> register (+ possibly delay slot adjustment), or from the single-step PC 
> (when we're single-stepping that is).  Or are you suggesting that the 
> pseudo-PC *should be* in the kernel (if not part of the pt_regs struct, 
> then at least accessible by ptrace)?

Precisely.  It sounds like the kernel can do a more accuarate job than
gdbserver can easily.  For instance, if we single-step a task, and
detach leaving it stopped, and attach another debugger - that debugger
won't have the state to know whether the task was last stepped or
trapped.

> >Not sure what you mean by this.
> 
> For example, in case of a PTRACE_CONT I set the single-step PC to 0 to 
> disable single-stepping (similar to what the m68k does).

Ah, I think I see.  I don't remember what your original question was
though :-)

-- 
Daniel Jacobowitz