From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19904 invoked by alias); 20 Feb 2003 15:08:19 -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 19897 invoked from network); 20 Feb 2003 15:08:18 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 20 Feb 2003 15:08:18 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18luCG-0000lC-00; Thu, 20 Feb 2003 11:09:21 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18lsJ4-0007Ys-00; Thu, 20 Feb 2003 10:08:14 -0500 Date: Thu, 20 Feb 2003 15:08:00 -0000 From: Daniel Jacobowitz To: Miles Bader Cc: gdb@sources.redhat.com Subject: Re: emulating single-step in gdbserver? Message-ID: <20030220150813.GA28933@nevyn.them.org> Mail-Followup-To: Miles Bader , gdb@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-02/txt/msg00407.txt.bz2 On Thu, Feb 20, 2003 at 01:39:25PM +0900, Miles Bader wrote: > Hi, > > I'm porting gdbserver to uClinux on the (NEC) v850e processor, and > ptrace on this machine doesn't support PTRACE_SINGLESTEP (because the > hardware doesn't support single-stepping). > > I thought gdb might already support an emulated singlestep by always > setting a temporary breakpoint at the next insn, but from a quick > perusal of the source, it seems not. > > So I'm wondering where the best place to stick this functionality is. GDB (i.e. the client, not gdbserver). Certainly gdbserver could do it, but you have to do some rather more complicated work in the server that GDB is already set up to do and the server isn't - with threads, for instance. Most other platforms do this; see ARM and MIPS at least. However, now that I've got limited breakpoint support in gdbserver, it might be practical to do it in the server. > The `next_pc' member added to the_low_target would be a function that > calculates the next pc after executing the current insn. > > Any comments on this approach; does it seem correct? Roughly. Another detail you'd get wrong would be if we get a signal before hitting the single-step breakpoint - it should be removed, not left for later. There are probably others. > A related question, BTW, is what's the precise meaning of > `the_low_target.breakpoint_reinsert_addr'? It's not documented very > well... It's essentially a very limitted next_pc function. The only breakpoints gdbserver places right now are in empty marker functions in the thread library. After hitting one, it either single-steps or places a breakpoint at the function's return address, and then reinserts it. The advantage is that finding the return address is quick and very simple. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer