This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Register fudging (CRISv32)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]