From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26659 invoked by alias); 20 Dec 2007 05:26:39 -0000 Received: (qmail 26643 invoked by uid 22791); 20 Dec 2007 05:26:38 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 20 Dec 2007 05:26:31 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id F1C5E2A9677 for ; Thu, 20 Dec 2007 00:26:29 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id k57GJLHuuw1c for ; Thu, 20 Dec 2007 00:26:29 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id C1EDC2A966C for ; Thu, 20 Dec 2007 00:26:28 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 0544DE7ACC; Thu, 20 Dec 2007 09:26:18 +0400 (RET) Date: Thu, 20 Dec 2007 05:40:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: Re: [RFC/RFA] continue stepping if landed in new range of same line Message-ID: <20071220052617.GE6154@adacore.com> References: <20071219075903.GA6184@adacore.com> <20071219141812.GA21072@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071219141812.GA21072@caradoc.them.org> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-12/txt/msg00327.txt.bz2 > I don't like your patch very much, since it assumes things about code > based on the structure of the source (and there are some pathological > cases, like functions which start in one file and end in another). To be honest, I didn't like it very much either. I didn't know about functions that start and end in different files! Is that through inlining? > I'd rather figure out if the above quoted code is still necessary. > If we were on the last line of the function and told to step, why > shouldn't we step out of it? I am guessing that this is to handle the following situation: void foo (void) { bar (); baz (); } When you break on foo, and then do a next: (gdb) break foo (gdb) cont [landing in foo, after function prologue] (gdb) next [executes "bar ();" statement, stops at call to baz] (gdb) next [executes "baz ();" statement, stops at epilogue] (gdb) next [step out of function] Personally, I have always considered that "next" was supposed to step until reaching a different line. But a discussion that we had internally at AdaCore a while back about something slightly different made me realize that it's not that obvious. Just to explain a bit more, we had some code like this: 10. Foo (Parameter_1 => 2.0, 11. Parameter_2 => Call_Me (Argument => 1), 12. Parameter_3 => Do_Nothing (Ignore => 3)); Some of the engineers were arguing that if we were stopped at line 10, then "next" should first get us to line 11 (call to Call_Me), and then line 11 (call to Do_Nothing), and then back to line 10 for the actual call to Foo. On the other hand, I was arguing that I expect the first next to land past the call to Foo. The debugger is actually not in complete control of what it does, since it depends on how the compiler generates the line info. But this illustrates why what I no longer see the semantics of the "next" command as obvious anymore. Back to our case above, I personally would argue that the first next should step all the way to out of the function. But whether this would be the most useful behavior depends on the user (type of code that he usually debugs, and how he likes to debug). I hope that one-lines above are very rare, and perhaps we should not worry about them. -- Joel