From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20906 invoked by alias); 3 Sep 2004 13:47:30 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20876 invoked from network); 3 Sep 2004 13:47:24 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 3 Sep 2004 13:47:24 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1C3EPR-0000HB-Ft; Fri, 03 Sep 2004 09:47:21 -0400 Date: Fri, 03 Sep 2004 13:47:00 -0000 From: Daniel Jacobowitz To: Orjan Friberg Cc: gdb@sources.redhat.com Subject: Re: Register fudging (CRISv32) Message-ID: <20040903134721.GA1028@nevyn.them.org> Mail-Followup-To: Orjan Friberg , gdb@sources.redhat.com References: <4138656F.9020001@axis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4138656F.9020001@axis.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-09/txt/msg00032.txt.bz2 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