From: Daniel Jacobowitz <drow@false.org>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC/RFA] continue stepping if landed in new range of same line
Date: Thu, 20 Dec 2007 14:08:00 -0000 [thread overview]
Message-ID: <20071220140023.GB7244@caradoc.them.org> (raw)
In-Reply-To: <20071220052617.GE6154@adacore.com>
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
next prev parent reply other threads:[~2007-12-20 14:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-19 12:59 Joel Brobecker
2007-12-19 14:18 ` Daniel Jacobowitz
2007-12-20 5:40 ` Joel Brobecker
2007-12-20 14:08 ` Daniel Jacobowitz [this message]
2007-12-21 6:28 ` Joel Brobecker
2007-12-21 14:01 ` Daniel Jacobowitz
2007-12-22 6:03 ` Joel Brobecker
2007-12-22 18:05 ` Daniel Jacobowitz
2007-12-24 6:41 ` Joel Brobecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071220140023.GB7244@caradoc.them.org \
--to=drow@false.org \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox