Register fudging (CRISv32)

Register fudging (CRISv32)

[Orjan Friberg]

My upcoming CRISv32 port (remote target, Linux based) is starting to 
look pretty good(*) but I'm left with a nagging feeling that the 
register fudging I'm doing isn't necessarily done where it should be 
and/or the right way.  Right now it's being done in three different 
places (this relating to debugging user-mode programs):

(1) in the kernel
(2) in the Gdbserver
(3) in GDB

Basically, what I would like to hear is people's opinions on how various 
kinds of register fudging should be done.

On to the details:

* The first fudging is the equivalent to DECR_PC_AFTER_BREAK, though 
it's not using that mechanism in GDB; instead it's being done in the 
kernel.  On one hand I feel more comfortable doing it in the kernel 
where I know exactly what happens; on the other hand the decrementation 
needs to be duplicated in, for example, a classic kernel gdb stub. 
Should I be using DECR_PC_AFTER_BREAK in GDB instead?  Or the 
implementation in the Gdbserver?

* Another fudging that takes place is the filling in of a pseudo-PC 
register (there is no actual PC register, so it's not present in struct 
pt_regs).  This is being done in the Gdbserver.  In addition, in case we 
stopped in a delay slot, I *may* need to look at the code to determine 
what the PC should be set to (meaning I can't rely on register contents 
alone).  I've found 3 cases where this needs to be done:

   (1) In case of a stop (break, h/w watchpoint, receiving a signal etc)
   (2) When unwinding a sigtramp frame
   (3) When loading a core dump (supply_gregset)

As of now, delay-slot-adjustment of the PC is only being done for the 
first case (normal stop), and it's also done in the Gdbserver.  The 
other two cases don't handle being stopped in a delay slot yet, though I 
have a hunch this could be done in GDB.

* In addition to this, I need to set the h/w single-step PC to 0 in the 
kernel at various times, but I've seen other architectures doing that 
and I feel pretty confident that is the right way to do it.

Thanks for any insights.


(*) the gdb.base testsuite results in about 6050 PASS and around 20 FAIL 
(the relatively new sigbpt.exp, siginfo.exp, signull.exp, and 
sigstep.exp are all PASS - yay!)

-- 
Orjan Friberg
Axis Communications

Re: Register fudging (CRISv32)

[Daniel Jacobowitz]

On Fri, Sep 03, 2004 at 02:37:03PM +0200, Orjan Friberg wrote:
> My upcoming CRISv32 port (remote target, Linux based) is starting to 
> look pretty good(*) but I'm left with a nagging feeling that the 
> register fudging I'm doing isn't necessarily done where it should be 
> and/or the right way.  Right now it's being done in three different 
> places (this relating to debugging user-mode programs):
> 
> (1) in the kernel
> (2) in the Gdbserver
> (3) in GDB
> 
> Basically, what I would like to hear is people's opinions on how various 
> kinds of register fudging should be done.
> 
> On to the details:
> 
> * The first fudging is the equivalent to DECR_PC_AFTER_BREAK, though 
> it's not using that mechanism in GDB; instead it's being done in the 
> kernel.  On one hand I feel more comfortable doing it in the kernel 
> where I know exactly what happens; on the other hand the decrementation 
> needs to be duplicated in, for example, a classic kernel gdb stub. 
> Should I be using DECR_PC_AFTER_BREAK in GDB instead?  Or the 
> implementation in the Gdbserver?

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.

> * Another fudging that takes place is the filling in of a pseudo-PC 
> register (there is no actual PC register, so it's not present in struct 
> pt_regs).  This is being done in the Gdbserver.  In addition, in case we 
> stopped in a delay slot, I *may* need to look at the code to determine 
> what the PC should be set to (meaning I can't rely on register contents 
> alone).  I've found 3 cases where this needs to be done:
> 
>   (1) In case of a stop (break, h/w watchpoint, receiving a signal etc)
>   (2) When unwinding a sigtramp frame
>   (3) When loading a core dump (supply_gregset)
> 
> As of now, delay-slot-adjustment of the PC is only being done for the 
> first case (normal stop), and it's also done in the Gdbserver.  The 
> other two cases don't handle being stopped in a delay slot yet, though I 
> have a hunch this could be done in GDB.

There's arguments both ways for this.  For instance, I think it would
be reasonable to do this in the kernel.

> * In addition to this, I need to set the h/w single-step PC to 0 in the 
> kernel at various times, but I've seen other architectures doing that 
> and I feel pretty confident that is the right way to do it.

Not sure what you mean by this.

-- 
Daniel Jacobowitz

Re: Register fudging (CRISv32)

[Orjan Friberg]

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

Re: Register fudging (CRISv32)

[Daniel Jacobowitz]

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

Re: Register fudging (CRISv32)

[Orjan Friberg]

Daniel Jacobowitz wrote:
> 
> 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.

I sort of see what you're saying (though I'm not sure I understand your 
example: the register contents would be the same when attaching again, 
which is what the pseudo-PC is calculated from).  Anyways, I'm going to 
try and implement the creation of the pseudo-PC in the kernel - I'm not 
entirely happy with having it in the Gdbserver, and it also has it flaws 
(for example, sigaltstack.exp generating several FAILs if we receive the 
signal in a delay slot).

>>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 :-)

It was just one example of register fudging that seemed appropriate to 
do in the kernel.

-- 
Orjan Friberg
Axis Communications