From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26081 invoked by alias); 27 Mar 2004 05:50:39 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 26062 invoked from network); 27 Mar 2004 05:50:37 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 27 Mar 2004 05:50:37 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B76iL-0002Tb-7p; Sat, 27 Mar 2004 00:50:37 -0500 Date: Sat, 27 Mar 2004 05:50:00 -0000 From: Daniel Jacobowitz To: Orjan Friberg Cc: gdb-patches@sources.redhat.com Subject: Re: Next over function and breakpoint setting Message-ID: <20040327055037.GA9418@nevyn.them.org> Mail-Followup-To: Orjan Friberg , gdb-patches@sources.redhat.com References: <40572066.2020304@axis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40572066.2020304@axis.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00695.txt.bz2 On Tue, Mar 16, 2004 at 04:42:30PM +0100, Orjan Friberg wrote: > Out of curiosity I followed what happens when issuing a next command > over a function call. The reason I got curious was that I noticed > (remote protocol) that GDB sets a breakpoint on the first instruction of > the function being stepped over, and, when stopped there, sets another > breakpoint at that function's return address to accomplish the "next". > > Actually, maybe that's a misrepresentation: looking at the code, it > seems GDB does a step, and if it *then* finds it ended up inside a > function (step_into_function -> step_over_function) it decides to step > out of it. > > Looking at the code in infcmd.c and infrun.c I'm sure there's a good > reason for not just setting the breakpoint on the address belonging to > the next line of code, but I couldn't find any comment saying what that > reason is. Anyone care to enlighten me? > > (I couldn't say if any of this was remote target/CRIS specific; > apologies if it is and I missed it.) [Sorry, missed this the first time.] "The next line of code" is a very iffy concept. GDB doesn't analyze a line to figure out what it does, or where it might transfer control to... while possible, that would be a very different approach to debugging. So the only way we have to implement next is to step and see where we end up - and if we don't like it, go until we're somewhere else. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer