From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10120 invoked by alias); 20 Dec 2007 14:00:33 -0000 Received: (qmail 10107 invoked by uid 22791); 20 Dec 2007 14:00:32 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 20 Dec 2007 14:00:26 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 0039B981FC; Thu, 20 Dec 2007 14:00:25 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id CD01298150; Thu, 20 Dec 2007 14:00:24 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1J5Lwl-00029D-QF; Thu, 20 Dec 2007 09:00:23 -0500 Date: Thu, 20 Dec 2007 14:08:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: [RFC/RFA] continue stepping if landed in new range of same line Message-ID: <20071220140023.GB7244@caradoc.them.org> Mail-Followup-To: Joel Brobecker , gdb-patches@sourceware.org References: <20071219075903.GA6184@adacore.com> <20071219141812.GA21072@caradoc.them.org> <20071220052617.GE6154@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071220052617.GE6154@adacore.com> User-Agent: Mutt/1.5.17 (2007-12-11) X-IsSubscribed: yes 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/msg00335.txt.bz2 On Thu, Dec 20, 2007 at 09:26:17AM +0400, Joel Brobecker wrote: > > 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? Much simpler than that. #define FN foo #include "start-fn.h" retval = arg1 + arg2; #include "end-fn.h" Finagle the comments just right and this will open on line 2 of start-fn.h and close on line 2 of end-fn.h. You might be able to arrange this with inlining or macros, too. > > 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 (); } Amusingly, when you copy and paste this into Emacs, it winds up in perfect GNU style on five lines... I ran the experiment. With the function on five lines, next goes from bar() to baz() and then to }. With the function on one line, it goes all the way from bar() back to the caller. So, maybe it was intended to handle this case, but it doesn't. My best guess is that it was design to handle a single-line function without a call, to prevent us from skipping from the prologue all the way out. But I think other measures will prevent that too. I think that code can probably change. But you might want to try debugging a couple of optimized cases to see if the behavior stays sensible... -- Daniel Jacobowitz CodeSourcery