This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Register fudging (CRISv32)
- From: Orjan Friberg <orjan dot friberg at axis dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 03 Sep 2004 16:30:39 +0200
- Subject: Re: Register fudging (CRISv32)
- Organization: Axis Communications
- References: <4138656F.9020001@axis.com> <20040903134721.GA1028@nevyn.them.org>
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)?
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).
--
Orjan Friberg
Axis Communications