This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Register fudging (CRISv32)
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