This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Register fudging (CRISv32)
- From: Daniel Jacobowitz <drow at false dot org>
- To: Orjan Friberg <orjan dot friberg at axis dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 3 Sep 2004 09:47:21 -0400
- Subject: Re: Register fudging (CRISv32)
- References: <4138656F.9020001@axis.com>
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