This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC/RFA] continue stepping if landed in new range of same line


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]