Getting pissed off by gdb. Please help with stepping in.

Getting pissed off by gdb. Please help with stepping in.

[temp]

I had to use gdb many times over the years all the time it pisses me off
with one of its features and makes me move back to microsoft debugger as
soon as possible. Now I want to get to the bottom of it and figure out if
it's me or gdb. I'm talking about stepping into a function. Imagine a call
to a function 'foo' that has one argument and the value of this argument
is returned by a call to another function 'bar' like:

...
foo( bar() );
...

All I want to do is to step into 'foo' without having to set any
additional breakpoints.

When I use microsoft debugger and do step into on this line I get into the
function 'bar' first. Than I step out what brings me back to the line
where 'foo' is called. I do another step into and get into 'foo'.

When I debug same code under gdb and do step into I get into 'bar'. So far
so good. I do a step out and wtf... Instead of getting back to the line
where 'foo' is called I get passed it. My step out of 'bar' command caused
call to 'foo' to execute as well. But I just wanted to step out of 'bar'
but not have 'foo' executed yet. Not happy.

So my question is it possible to step out of a function in gdb in code
like above and remain on the line where this function was called from?
What's the secret? Please advise.

Pavel

Re: Getting pissed off by gdb. Please help with stepping in.

[Hui Zhu]

s
#step into bar
finish
#finish the bar and into foo

On Thu, Mar 18, 2010 at 10:39,  <temp@sourceboost.com> wrote:
> I had to use gdb many times over the years all the time it pisses me off
> with one of its features and makes me move back to microsoft debugger as
> soon as possible. Now I want to get to the bottom of it and figure out if
> it's me or gdb. I'm talking about stepping into a function. Imagine a call
> to a function 'foo' that has one argument and the value of this argument
> is returned by a call to another function 'bar' like:
>
> ...
> foo( bar() );
> ...
>
> All I want to do is to step into 'foo' without having to set any
> additional breakpoints.
>
> When I use microsoft debugger and do step into on this line I get into the
> function 'bar' first. Than I step out what brings me back to the line
> where 'foo' is called. I do another step into and get into 'foo'.
>
> When I debug same code under gdb and do step into I get into 'bar'. So far
> so good. I do a step out and wtf... Instead of getting back to the line
> where 'foo' is called I get passed it. My step out of 'bar' command caused
> call to 'foo' to execute as well. But I just wanted to step out of 'bar'
> but not have 'foo' executed yet. Not happy.
>
> So my question is it possible to step out of a function in gdb in code
> like above and remain on the line where this function was called from?
> What's the secret? Please advise.
>
> Pavel
>
>
>
>
>
>

Re: Getting pissed off by gdb. Please help with stepping in.

[Nathan Froyd]

On Wed, Mar 17, 2010 at 10:39:44PM -0400, temp@sourceboost.com wrote:
> When I debug same code under gdb and do step into I get into 'bar'. So far
> so good. I do a step out and wtf... Instead of getting back to the line
> where 'foo' is called I get passed it. My step out of 'bar' command caused
> call to 'foo' to execute as well. But I just wanted to step out of 'bar'
> but not have 'foo' executed yet. Not happy.
> 
> So my question is it possible to step out of a function in gdb in code
> like above and remain on the line where this function was called from?
> What's the secret? Please advise.

I think the command you want to use, once you've 'step'd into bar is
'finish'.

You don't say what you're using to "step out" of bar in GDB, so it's
possible you're already following my suggestion.

-Nathan

Re: Getting pissed off by gdb. Please help with stepping in.

[Doug Evans]

On Wed, Mar 17, 2010 at 7:39 PM,  <temp@sourceboost.com> wrote:
> I had to use gdb many times over the years all the time it pisses me off
> with one of its features and makes me move back to microsoft debugger as
> soon as possible. Now I want to get to the bottom of it and figure out if
> it's me or gdb. I'm talking about stepping into a function. Imagine a call
> to a function 'foo' that has one argument and the value of this argument
> is returned by a call to another function 'bar' like:
>
> ...
> foo( bar() );
> ...
>
> All I want to do is to step into 'foo' without having to set any
> additional breakpoints.
>
> When I use microsoft debugger and do step into on this line I get into the
> function 'bar' first. Than I step out what brings me back to the line
> where 'foo' is called. I do another step into and get into 'foo'.
>
> When I debug same code under gdb and do step into I get into 'bar'. So far
> so good. I do a step out and wtf... Instead of getting back to the line
> where 'foo' is called I get passed it. My step out of 'bar' command caused
> call to 'foo' to execute as well. But I just wanted to step out of 'bar'
> but not have 'foo' executed yet. Not happy.
>
> So my question is it possible to step out of a function in gdb in code
> like above and remain on the line where this function was called from?
> What's the secret? Please advise.

I agree it should work as you expect.  I don't see the step out of bar
continuing passed foo, but I do see it stepping into foo (as if you
had done two steps, so to speak: step out of bar and step into foo).
[This is with gdb 7.0 and cvs head.]
One *could* use `finish' to accomplish what you want but I think a
`step' at the end of the function should behave like `finish' (modulo
printing the return value of course).

This patch for cvs head gets things working for me.  I haven't run it
through the testsuite, and it might be nice compare more than just
frame ids (and for the gdb crowd, yes, the FIXME needs to go before
being checked in ...), but .... this patch seems otherwise reasonable
to me.  At the point where the patch is applied gdb has already
decided to continue - what's a case where it *should* continue at this
point *if* the frame has changed?  [Note that gdb has already handled
various cases like stopping in trampolines and such.]

diff -u -p -r1.434 infrun.c
--- infrun.c    14 Mar 2010 17:35:21 -0000      1.434
+++ infrun.c    18 Mar 2010 07:11:29 -0000
@@ -4770,6 +4770,23 @@ infrun: not switching back to stepped th
       return;
     }

+  /* See if we stepped out of a function into its caller.  */
+  /* FIXME: IWBN to do an inner-than test on the stack addresses
+     but that doesn't necessarily work in a split-stack environment.
+     Or we could call frame_unwind_caller_id (step_stack_frame_id),
+     but that seems dubious.  */
+
+  if (!frame_id_eq (get_stack_frame_id (frame),
+                   ecs->event_thread->step_stack_frame_id))
+    {
+      if (debug_infrun)
+        fprintf_unfiltered (gdb_stdlog, "infrun: stepped out of function\n");
+      ecs->event_thread->stop_step = 1;
+      print_stop_reason (END_STEPPING_RANGE, 0);
+      stop_stepping (ecs);
+      return;
+    }
+
   /* We aren't done stepping.

      Optimize by setting the stepping range to the line.

Re: Getting pissed off by gdb. Please help with stepping in.

[Eli Zaretskii]

> Date: Thu, 18 Mar 2010 00:22:20 -0700
> From: Doug Evans <dje@google.com>
> Cc: gdb@sourceware.org
> 
> I agree it should work as you expect.  I don't see the step out of bar
> continuing passed foo, but I do see it stepping into foo (as if you
> had done two steps, so to speak: step out of bar and step into foo).
> [This is with gdb 7.0 and cvs head.]
> One *could* use `finish' to accomplish what you want but I think a
> `step' at the end of the function should behave like `finish' (modulo
> printing the return value of course).

I'm confused: what exactly does this patch fix, i.e. what was the
behavior before it and what it will be after it?

My confusion stems from the fact that you first say that the problem
described by the OP does not exist, i.e. GDB does _not_ continue past
foo, but then you say something is wrong and suggest a fix.  What did
I miss here?

Thanks.

Re: Getting pissed off by gdb. Please help with stepping in.

[Doug Evans]

On Thu, Mar 18, 2010 at 2:07 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 18 Mar 2010 00:22:20 -0700
>> From: Doug Evans <dje@google.com>
>> Cc: gdb@sourceware.org
>>
>> I agree it should work as you expect.  I don't see the step out of bar
>> continuing passed foo, but I do see it stepping into foo (as if you
>> had done two steps, so to speak: step out of bar and step into foo).
>> [This is with gdb 7.0 and cvs head.]
>> One *could* use `finish' to accomplish what you want but I think a
>> `step' at the end of the function should behave like `finish' (modulo
>> printing the return value of course).
>
> I'm confused: what exactly does this patch fix, i.e. what was the
> behavior before it and what it will be after it?
>
> My confusion stems from the fact that you first say that the problem
> described by the OP does not exist, i.e. GDB does _not_ continue past
> foo, but then you say something is wrong and suggest a fix.  What did
> I miss here?

Suppose we have this code:

int g;

int bar () { return 1; }

void foo (int x) { g = x; }

int
main ()
{
  foo (bar ());
  return 0;
}

And suppose we've stepped into `bar' during the setup for the call to `foo'.

(gdb) start
Temporary breakpoint 1 at 0x4003ad: file stepout.c, line 11.
Starting program: /home/dje/src/play/stepout.x64

Temporary breakpoint 1, main () at stepout.c:11
11        foo (bar ());
(gdb) s
bar () at stepout.c:4
4       int bar () { return 1; }
(gdb)

Now suppose the user does a "step" at this point.
There are several possibilities for what can happen, and that is what
we are discussing.
Here's what gdb 7.1 does:

(gdb) f
#0  bar () at stepout.c:4
4       int bar () { return 1; }
(gdb) s
foo (x=1) at stepout.c:6
6       void foo (int x) { g = x; }
(gdb)

Note that we've stepped out of bar and into foo.

Here is what Pavel is expecting instead:

(gdb) f
#0  bar () at stepout.c:4
4       int bar () { return 1; }
(gdb) s
0x00000000004003b7 in main () at stepout.c:11
11        foo (bar ());
(gdb)

[or some such. I cut-n-pasted that from a session with my patch
applied. IWBN to remove all those zeroes in 0x00000... of course]
Note that we've stepped out of bar but have not yet stepped into foo.

The behaviour Pavel describes in his message, but which I do not see, is this:

(gdb) f
#0  bar () at stepout.c:4
4       int bar () { return 1; }
(gdb) s
main () at stepout.c:12
12        return 0;
(gdb)

Note that we've stepped out of bar, into foo, and back out of foo.

Re: Getting pissed off by gdb. Please help with stepping in.

[Pedro Alves]

On Thursday 18 March 2010 15:10:41, Doug Evans wrote:
> The behaviour Pavel describes in his message, but which I do not see, is this:
> 
> (gdb) f
> #0  bar () at stepout.c:4
> 4       int bar () { return 1; }
> (gdb) s
> main () at stepout.c:12
> 12        return 0;
> (gdb)
> 
> Note that we've stepped out of bar, into foo, and back out of foo.

He most probably used "next" when he said:

> I do a step out and wtf... Instead of getting back to the line
> where 'foo' is called I get passed it.

-- 
Pedro Alves

Re: Getting pissed off by gdb. Please help with stepping in.

[Eli Zaretskii]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Thu, 18 Mar 2010 15:21:48 +0000
> Cc: Doug Evans <dje@google.com>,
>  Eli Zaretskii <eliz@gnu.org>,
>  temp@sourceboost.com
> 
> On Thursday 18 March 2010 15:10:41, Doug Evans wrote:
> > The behaviour Pavel describes in his message, but which I do not see, is this:
> > 
> > (gdb) f
> > #0  bar () at stepout.c:4
> > 4       int bar () { return 1; }
> > (gdb) s
> > main () at stepout.c:12
> > 12        return 0;
> > (gdb)
> > 
> > Note that we've stepped out of bar, into foo, and back out of foo.
> 
> He most probably used "next" when he said:
> 
> > I do a step out and wtf... Instead of getting back to the line
> > where 'foo' is called I get passed it.

I would expect "next" on line 4 to behave the same as "step", since
there's no function call there.

Re: Getting pissed off by gdb. Please help with stepping in.

[Pedro Alves]

On Thursday 18 March 2010 18:32:34, Eli Zaretskii wrote:
> > > (gdb) f
> > > #0  bar () at stepout.c:4
> > > 4       int bar () { return 1; }
> > > (gdb) s
> > > main () at stepout.c:12
> > > 12        return 0;
> > > (gdb)
> > > 
> > > Note that we've stepped out of bar, into foo, and back out of foo.
> > 
> > He most probably used "next" when he said:
> > 
> > > I do a step out and wtf... Instead of getting back to the line
> > > where 'foo' is called I get passed it.
> 
> I would expect "next" on line 4 to behave the same as "step", since
> there's no function call there.

But it doesn't.  You're missing the issue.  "step" on line 4 will
take you to line 6, instead of line 11, because GDB keeps stepping
after returning from bar (because it landed in the middle
of line 11, and we don't stop there when stepping/nexting).

Next on line 4 will take you to line 12, instead of line 11,
because GDB keeps stepping after returning from bar (because
it landed in the middle of line 11, and we don't stop there
when stepping/nexting).

Users often find this behaviour unexpected (I've often
wished GDB would behave like what the OP is suggesting too).

In the example being discussed, the OP would have expected
that GDB would stop at line 11, when "stepping out of bar",
but found GDB stopping at line 12 instead.  I was saying that
what he was probably calling "stepping", was issueing enough
"next"s to step out of bar, not "step"s.  I don't suppose
people wanting to step out of a function (not knowing about
finish) would issue "(gdb) step"s and risk stepping
into further nested functions...

I was pointing that out, after reading Doug's:

> "I agree it should work as you expect.  I don't see the step out of bar
> continuing passed foo, but I do see it stepping into foo (as if you
> had done two steps, so to speak: step out of bar and step into foo).
> [This is with gdb 7.0 and cvs head.]"

So, I'm merely saying that to reproduce what the OP was saying,
you should do "next" to step out of bar, not "step".

  Visual Studio's "Step (Over)"  ==> "(gdb) next"
  Visual Studio's "Step Into"  ==> "(gdb) step"

In any case, the behaviour would not be what the OP expected.

-- 
Pedro Alves

Re: Getting pissed off by gdb. Please help with stepping in.

[Eli Zaretskii]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Thu, 18 Mar 2010 18:55:39 +0000
> Cc: dje@google.com,
>  temp@sourceboost.com
> 
> Users often find this behaviour unexpected (I've often
> wished GDB would behave like what the OP is suggesting too).

Then why don't we change the behavior to match what users expect?

Re: Getting pissed off by gdb. Please help with stepping in.

[Mark Kettenis]

> Date: Thu, 18 Mar 2010 21:38:18 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Pedro Alves <pedro@codesourcery.com>
> > Date: Thu, 18 Mar 2010 18:55:39 +0000
> > Cc: dje@google.com,
> >  temp@sourceboost.com
> > 
> > Users often find this behaviour unexpected (I've often
> > wished GDB would behave like what the OP is suggesting too).
> 
> Then why don't we change the behavior to match what users expect?

Because different users expect different things.  I for example would
be somewhat annoyed by having to issue an extra "step".  And the
argument that this is what people that are familliar with Visual
Studio are used to is pretty weak.  GDB users are used the GDB behaviour!

Re: Getting pissed off by gdb. Please help with stepping in.

[Doug Evans]

On Thu, Mar 18, 2010 at 12:53 PM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> Date: Thu, 18 Mar 2010 21:38:18 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>>
>> > From: Pedro Alves <pedro@codesourcery.com>
>> > Date: Thu, 18 Mar 2010 18:55:39 +0000
>> > Cc: dje@google.com,
>> >  temp@sourceboost.com
>> >
>> > Users often find this behaviour unexpected (I've often
>> > wished GDB would behave like what the OP is suggesting too).
>>
>> Then why don't we change the behavior to match what users expect?
>
> Because different users expect different things.  I for example would
> be somewhat annoyed by having to issue an extra "step".  And the
> argument that this is what people that are familliar with Visual
> Studio are used to is pretty weak.  GDB users are used the GDB behaviour!

That argument is pretty weak too IMO.
This isn't a VS vs GDB discussion.

Re: Getting pissed off by gdb. Please help with stepping in.

[Michael Snyder]

Doug Evans wrote:
> On Thu, Mar 18, 2010 at 12:53 PM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>>> Date: Thu, 18 Mar 2010 21:38:18 +0200
>>> From: Eli Zaretskii <eliz@gnu.org>
>>>
>>>> From: Pedro Alves <pedro@codesourcery.com>
>>>> Date: Thu, 18 Mar 2010 18:55:39 +0000
>>>> Cc: dje@google.com,
>>>>  temp@sourceboost.com
>>>>
>>>> Users often find this behaviour unexpected (I've often
>>>> wished GDB would behave like what the OP is suggesting too).
>>> Then why don't we change the behavior to match what users expect?
>> Because different users expect different things.  I for example would
>> be somewhat annoyed by having to issue an extra "step".  And the
>> argument that this is what people that are familliar with Visual
>> Studio are used to is pretty weak.  GDB users are used the GDB behaviour!
> 
> That argument is pretty weak too IMO.
> This isn't a VS vs GDB discussion.

Am I the only one who remembers that gdb used to have the behavior that
is being discussed, and it was deliberately changed to behave the way it
does today?

My admittedly fallable memory cells are telling me that it was Fernando
Nasser who championed the change, which means that it would have been
at least five years ago.

If I am right, the argument then was that the new behavior (what gdb
has today) was closer to what users would expect.

Re: Getting pissed off by gdb. Please help with stepping in.

[Pedro Alves]

On Thursday 18 March 2010 20:51:46, Michael Snyder wrote:
> Am I the only one who remembers that gdb used to have the behavior that
> is being discussed, and it was deliberately changed to behave the way it
> does today?
> 
> My admittedly fallable memory cells are telling me that it was Fernando
> Nasser who championed the change, which means that it would have been
> at least five years ago.
> 
> If I am right, the argument then was that the new behavior (what gdb
> has today) was closer to what users would expect.

Perhaps it was "step-mode" instead (or changing it's default)?  You
mentioned a command/setting for what you thought remembered, but
what we're discussing doesn't have a knob...

(gdb) help set step-mode
Set mode of the step operation.
When set, doing a step over a function without debug line information
will stop at the first instruction of that function. Otherwise, the
function is skipped and the step command stops at a different source line.

-- 
Pedro Alves

Re: Getting pissed off by gdb. Please help with stepping in.

[Eli Zaretskii]

> Date: Thu, 18 Mar 2010 20:53:09 +0100 (CET)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: pedro@codesourcery.com, gdb@sourceware.org, dje@google.com,
>         temp@sourceboost.com
> 
> > Date: Thu, 18 Mar 2010 21:38:18 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > > From: Pedro Alves <pedro@codesourcery.com>
> > > Date: Thu, 18 Mar 2010 18:55:39 +0000
> > > Cc: dje@google.com,
> > >  temp@sourceboost.com
> > > 
> > > Users often find this behaviour unexpected (I've often
> > > wished GDB would behave like what the OP is suggesting too).
> > 
> > Then why don't we change the behavior to match what users expect?
> 
> Because different users expect different things.  I for example would
> be somewhat annoyed by having to issue an extra "step".  And the
> argument that this is what people that are familliar with Visual
> Studio are used to is pretty weak.  GDB users are used the GDB behaviour!

Well, I'm a GDB user and almost never use Studio, but this behavior
surprises me.  What do you make of that?

Re: Getting pissed off by gdb. Please help with stepping in.

[Paul Hilfinger]

Mark Kettenis <mark.kettenis@xs4all.nl> wrote:

> > Date: Thu, 18 Mar 2010 21:38:18 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > > From: Pedro Alves <pedro@codesourcery.com>
> > > Date: Thu, 18 Mar 2010 18:55:39 +0000
> > > Cc: dje@google.com,
> > >  temp@sourceboost.com
> > > 
> > > Users often find this behaviour unexpected (I've often
> > > wished GDB would behave like what the OP is suggesting too).
> > 
> > Then why don't we change the behavior to match what users expect?
> 
> Because different users expect different things.  I for example would
> be somewhat annoyed by having to issue an extra "step".  And the
> argument that this is what people that are familliar with Visual
> Studio are used to is pretty weak.  GDB users are used the GDB behaviour!

I have to agree with Eli here.  Yes, I suppose I am "used to" GDB
behaviour, but there are two senses to this phrase: (1) "have become
accustomed to and now prefer" and (2) "have learned to tolerate". After
all, there is no contradiction between the two statements "I've gotten
used to the howling blizzards that strike here every couple of days" and
"I'd really appreciate a transfer to Maui."  

The problem is that usually, if you are on line L1, 'step' brings you to
a line L2 that has some simple relationship with L1: it's (roughly) the
next statement to be executed after L1 in the current function or the
first statement to be executed in a function call at L1.  If L1 is the
end of a function, on the other hand, then L2 could be the first
statement of any other function, and is in fact unpredictable from the
text surrounding L1.  Well, this isn't so bad if you got to L1 by a
sequence of 'steps' starting at the call that directs you into L1's
function, because in principle, you might be expected to retain some
vague memory that you got to L1 from a call that would later take you to
L2.  But what if you landed in L1's function as a result of breakpoint?

Yes, I know: judicious use of 'up' and 'down' or 'where' will reorient
me.  But that just means that I save one 'step' at the cost of issuing
another, different, instruction.

And as I think others have pointed out, the user who wishes to bounce
back to the call statement must interpolate a 'finish' command at the
right point in his sequence of 'step's, something I must confess I
often manage to mess up.

Paul Hilfinger

Re: Getting pissed off by gdb. Please help with stepping in.

[Richard Earnshaw]

On Thu, 2010-03-18 at 20:53 +0100, Mark Kettenis wrote:
> > Date: Thu, 18 Mar 2010 21:38:18 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > > From: Pedro Alves <pedro@codesourcery.com>
> > > Date: Thu, 18 Mar 2010 18:55:39 +0000
> > > Cc: dje@google.com,
> > >  temp@sourceboost.com
> > > 
> > > Users often find this behaviour unexpected (I've often
> > > wished GDB would behave like what the OP is suggesting too).
> > 
> > Then why don't we change the behavior to match what users expect?
> 
> Because different users expect different things.  I for example would
> be somewhat annoyed by having to issue an extra "step".  And the
> argument that this is what people that are familliar with Visual
> Studio are used to is pretty weak.  GDB users are used the GDB behaviour!


They might be used to it, but that won't stop them hating it!  I'm in
agreement with those that want step at the end of a function to not
enter then next call.  It's a right royal pain having to have a sequence
such as 


        step
        <ret>
        <ret>
        <ret>

&*%^%^£$*&(*^ I've done one too many <ret>s, now I've got to restart my
debugging session and do it all again

        step
        <ret>
        <ret>
        finish
        step

R.

Re: Getting pissed off by gdb. Please help with stepping in.

[Mark Kettenis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]

> From: Richard Earnshaw <rearnsha@arm.com>
> Date: Fri, 19 Mar 2010 09:51:04 +0000
> 
> On Thu, 2010-03-18 at 20:53 +0100, Mark Kettenis wrote:
>
> > Because different users expect different things.  I for example would
> > be somewhat annoyed by having to issue an extra "step".  And the
> > argument that this is what people that are familliar with Visual
> > Studio are used to is pretty weak.  GDB users are used the GDB behaviour!
> 
> They might be used to it, but that won't stop them hating it!  I'm in
> agreement with those that want step at the end of a function to not
> enter then next call.  It's a right royal pain having to have a sequence
> such as 
> 
>         step
>         <ret>
>         <ret>
>         <ret>
> 
> &*%^%^£$*&(*^ I've done one too many <ret>s, now I've got to restart my
> debugging session and do it all again
> 
>         step
>         <ret>
>         <ret>
>         finish
>         step

Sorry, but I must be missing something.  Howe can you end up doing too
many "step"s in the foo(bar()) scenario?  I mean, if you do one step
too many, finding yourself stepping into foo() wheras you really
wanted to step over foo(), you can simply use "finish".  There is no
need to restart your session.

Re: Getting pissed off by gdb. Please help with stepping in.

[Eli Zaretskii]

> Date: Fri, 19 Mar 2010 11:39:20 +0100 (CET)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: eliz@gnu.org, pedro@codesourcery.com, gdb@sourceware.org, dje@google.com,
>         temp@sourceboost.com
> 
> Sorry, but I must be missing something.  Howe can you end up doing too
> many "step"s in the foo(bar()) scenario?  I mean, if you do one step
> too many, finding yourself stepping into foo() wheras you really
> wanted to step over foo(), you can simply use "finish".

In this simple example, maybe.  But in more complex situations (e.g.,
when arguments to `foo' include more function calls), not necessarily.

Re: Getting pissed off by gdb. Please help with stepping in.

[André Pönitz]

On Thursday 18 March 2010 20:53:09 Mark Kettenis wrote:
> > Date: Thu, 18 Mar 2010 21:38:18 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > > From: Pedro Alves <pedro@codesourcery.com>
> > > Date: Thu, 18 Mar 2010 18:55:39 +0000
> > > Cc: dje@google.com,
> > >  temp@sourceboost.com
> > > 
> > > Users often find this behaviour unexpected (I've often
> > > wished GDB would behave like what the OP is suggesting too).
> > 
> > Then why don't we change the behavior to match what users expect?
> 
> Because different users expect different things.  I for example would
> be somewhat annoyed by having to issue an extra "step". 

I am regularly annoyed by stepping "unexpectedly" too far. And that's
much harder to undo then doing an extra "step".

> And the argument that this is what people that are familliar with Visual
> Studio are used to is pretty weak.  GDB users are used the GDB behaviour!

That can't be true as a universal proposition as I know at least one
counterexample ;-)

I am personally much more of a GDB than a VS user but I live in an 
environment where people switch operating systems and compilers 
on a regular base, sometimes by the hour.

Being able to transfer skills and "finger memory" between these worlds
without having to completely reboot the brain is a big time saver. Not to
mention that it one has a pretty tough standing when trying to explain
to a user why his IDE behaves completely different when he "only" switched
compilers.

Anyway, it pretty much looks like there are quite a few people not really
opposed to having the "other" behaviour. So maybe we could switch
nevertheless -- or maybe having Yet Another Flag would be a solution
that makes all of us happy?

Andre'

Re: Getting pissed off by gdb. Please help with stepping in.

[Doug Evans]

On Thu, Mar 18, 2010 at 8:10 AM, Doug Evans <dje@google.com> wrote:
> The behaviour Pavel describes in his message, but which I do not see, is this:
>
> (gdb) f
> #0  bar () at stepout.c:4
> 4       int bar () { return 1; }
> (gdb) s
> main () at stepout.c:12
> 12        return 0;
> (gdb)
>
> Note that we've stepped out of bar, into foo, and back out of foo.

Although ...

Pavel wrote:
> [...] My step out of 'bar' command caused
> call to 'foo' to execute as well. But I just wanted to step out of 'bar'
> but not have 'foo' executed yet.

could instead mean that we've stepped into foo, i.e. gdb's current
behaviour.  Heh.
Still, I've also tripped over doing a step at the end of a function
and ended up not back in the caller, but in another subroutine - and
wish that hadn't happened.

Re: Getting pissed off by gdb. Please help with stepping in.

[Eli Zaretskii]

> Date: Thu, 18 Mar 2010 08:10:41 -0700
> From: Doug Evans <dje@google.com>
> Cc: temp@sourceboost.com, gdb@sourceware.org
> 
> Here's what gdb 7.1 does:
> 
> (gdb) f
> #0  bar () at stepout.c:4
> 4       int bar () { return 1; }
> (gdb) s
> foo (x=1) at stepout.c:6
> 6       void foo (int x) { g = x; }
> (gdb)
> 
> Note that we've stepped out of bar and into foo.
> 
> Here is what Pavel is expecting instead:
> 
> (gdb) f
> #0  bar () at stepout.c:4
> 4       int bar () { return 1; }
> (gdb) s
> 0x00000000004003b7 in main () at stepout.c:11
> 11        foo (bar ());
> (gdb)

Thanks.  But why is ``what Pavel is expecting'' useful?  What use-case
does it handle that the v7.1 behavior does not?

RE: Getting pissed off by gdb. Please help with stepping in.

[Paul Koning]

I'd say it is useful because it matches the documentation.  "s" is
documented as "run until you're at a different source line".  In
foo(bar()), the source line you come to after exit from bar() is the
call to foo(), not the first line of foo -- that would take "s 2".

	paul

> -----Original Message-----
> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
> Behalf Of Eli Zaretskii
> Sent: Thursday, March 18, 2010 2:31 PM
> To: Doug Evans
> Cc: temp@sourceboost.com; gdb@sourceware.org
> Subject: Re: Getting pissed off by gdb. Please help with stepping in.
> 
> > Date: Thu, 18 Mar 2010 08:10:41 -0700
> > From: Doug Evans <dje@google.com>
> > Cc: temp@sourceboost.com, gdb@sourceware.org
> >
> > Here's what gdb 7.1 does:
> >
> > (gdb) f
> > #0  bar () at stepout.c:4
> > 4       int bar () { return 1; }
> > (gdb) s
> > foo (x=1) at stepout.c:6
> > 6       void foo (int x) { g = x; }
> > (gdb)
> >
> > Note that we've stepped out of bar and into foo.
> >
> > Here is what Pavel is expecting instead:
> >
> > (gdb) f
> > #0  bar () at stepout.c:4
> > 4       int bar () { return 1; }
> > (gdb) s
> > 0x00000000004003b7 in main () at stepout.c:11
> > 11        foo (bar ());
> > (gdb)
> 
> Thanks.  But why is ``what Pavel is expecting'' useful?  What use-case
> does it handle that the v7.1 behavior does not?

Re: Getting pissed off by gdb. Please help with stepping in.

[Doug Evans]

To me it's the difference between stepping during

  foo(1);

and

  foo (bar());

In the former, the last "step" that returns from foo returns to the
caller - it's intuitive and what I expect.
In the latter, the last "step" in bar doesn't return to the caller,
instead it proceeds until we get into foo.  I just stepped out of a
function - how come I've also stepped into another function?

Also, when typing "s" and then constantly hitting <return> to move
things along, it's useful to see that extra step in the flow of the
program: the point between the return from bar and the call to foo.

As a data point, there is a time where stepping does stop in the
middle of a source line: next over longjmp (he says after having just
revisited why longjmp.exp has failures on amd64 (pointer mangling) and
tried it on i386).  According to the thread from bug 9270, the
intended fix IIUC is to keep stepping through the longjmp until it
returns - I wonder if there's an overlap here.

On Thu, Mar 18, 2010 at 11:37 AM, Paul Koning <Paul_Koning@dell.com> wrote:
> I'd say it is useful because it matches the documentation.  "s" is
> documented as "run until you're at a different source line".  In
> foo(bar()), the source line you come to after exit from bar() is the
> call to foo(), not the first line of foo -- that would take "s 2".
>
>        paul
>
>> -----Original Message-----
>> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
>> Behalf Of Eli Zaretskii
>> Sent: Thursday, March 18, 2010 2:31 PM
>> To: Doug Evans
>> Cc: temp@sourceboost.com; gdb@sourceware.org
>> Subject: Re: Getting pissed off by gdb. Please help with stepping in.
>>
>> > Date: Thu, 18 Mar 2010 08:10:41 -0700
>> > From: Doug Evans <dje@google.com>
>> > Cc: temp@sourceboost.com, gdb@sourceware.org
>> >
>> > Here's what gdb 7.1 does:
>> >
>> > (gdb) f
>> > #0  bar () at stepout.c:4
>> > 4       int bar () { return 1; }
>> > (gdb) s
>> > foo (x=1) at stepout.c:6
>> > 6       void foo (int x) { g = x; }
>> > (gdb)
>> >
>> > Note that we've stepped out of bar and into foo.
>> >
>> > Here is what Pavel is expecting instead:
>> >
>> > (gdb) f
>> > #0  bar () at stepout.c:4
>> > 4       int bar () { return 1; }
>> > (gdb) s
>> > 0x00000000004003b7 in main () at stepout.c:11
>> > 11        foo (bar ());
>> > (gdb)
>>
>> Thanks.  But why is ``what Pavel is expecting'' useful?  What use-case
>> does it handle that the v7.1 behavior does not?
>

Re: Getting pissed off by gdb. Please help with stepping in.

[Jonas Maebe]

On 18 Mar 2010, at 20:06, Doug Evans wrote:

> In the former, the last "step" that returns from foo returns to the
> caller - it's intuitive and what I expect.
> In the latter, the last "step" in bar doesn't return to the caller,
> instead it proceeds until we get into foo.  I just stepped out of a
> function - how come I've also stepped into another function?

FWIW, I'd also prefer the "step" to take the detour via the caller.


Jonas

Re: Getting pissed off by gdb. Please help with stepping in.

[Daniel Jacobowitz]

On Thu, Mar 18, 2010 at 12:22:20AM -0700, Doug Evans wrote:
> This patch for cvs head gets things working for me.  I haven't run it
> through the testsuite, and it might be nice compare more than just
> frame ids (and for the gdb crowd, yes, the FIXME needs to go before
> being checked in ...), but .... this patch seems otherwise reasonable
> to me.  At the point where the patch is applied gdb has already
> decided to continue - what's a case where it *should* continue at this
> point *if* the frame has changed?  [Note that gdb has already handled
> various cases like stopping in trampolines and such.]

In addition to what Eli said... here's the previous block:

  if ((stop_pc == stop_pc_sal.pc)
      && (ecs->event_thread->current_line != stop_pc_sal.line
          || ecs->event_thread->current_symtab != stop_pc_sal.symtab))
    {
      /* We are at the start of a different line.  So stop.  Note that
         we don't stop if we step into the middle of a different line.
         That is said to make things like for (;;) statements work
         better.  */

IOW, if we are at a line boundary, we stop stepping.  If we've ended
up in the middle of a line, we keep going.  This prevents us from
ending up in a weird state where we show the line containing the
function call, but the function has already been called.  I think it'd
be even more confusing.

This is a difference between stepping out of a function and finishing.

Now, if you end up in a different function while continuing to step
(or "next"), there's a good argument that you should stop...

-- 
Daniel Jacobowitz
CodeSourcery

Re: Getting pissed off by gdb. Please help with stepping in.

[André Pönitz]

On Thursday 18 March 2010 14:33:37 Daniel Jacobowitz wrote:
> On Thu, Mar 18, 2010 at 12:22:20AM -0700, Doug Evans wrote:
> > This patch for cvs head gets things working for me.  I haven't run it
> > through the testsuite, and it might be nice compare more than just
> > frame ids (and for the gdb crowd, yes, the FIXME needs to go before
> > being checked in ...), but .... this patch seems otherwise reasonable
> > to me.  At the point where the patch is applied gdb has already
> > decided to continue - what's a case where it *should* continue at this
> > point *if* the frame has changed?  [Note that gdb has already handled
> > various cases like stopping in trampolines and such.]
> 
> In addition to what Eli said... here's the previous block:
> 
>   if ((stop_pc == stop_pc_sal.pc)
>       && (ecs->event_thread->current_line != stop_pc_sal.line
>           || ecs->event_thread->current_symtab != stop_pc_sal.symtab))
>     {
>       /* We are at the start of a different line.  So stop.  Note that
>          we don't stop if we step into the middle of a different line.
>          That is said to make things like for (;;) statements work
>          better.  */
> 
> IOW, if we are at a line boundary, we stop stepping.  If we've ended
> up in the middle of a line, we keep going.  This prevents us from
> ending up in a weird state where we show the line containing the
> function call, but the function has already been called.  I think it'd
> be even more confusing.

Since this code turns up in discussion: The condition fires back in case
of an ill-behaved remote stub.

I unfortunately have to care for such a beast that sometimes "overshoots" 
when stepping over a range by two or three instructions. In this case the
condition is false and gdb will execute the code below the the block
leading to

  keep_going (ecs);

This means a 'next' effectively jumps over two lines, which is rather nasty.
So I have been removing this optimization in gdb for a while (as the stub 
is not under my control) without experiencing any bad side effects. Most
notably, stepping over  for (;;) does not seem to be affected at all.

I understand the (for me unfortunate) gdb behaviour  this is entirely the 
fault of the stub, but nevertheless I wonder whether this optimization is
really needed.

I dug a bit in gdb's history, and the code is older than anything I could 
access, i.e. before 1991 or so.  Together with the comment "That is said 
to make things like for (;;) statements work better" one might get the 
impression that it was a workaround for some particular compiler or such.

Does anybody happen to remember what triggered the inclusion of this
optimization into gdb code?

Andre'

Re: Getting pissed off by gdb. Please help with stepping in.

[Daniel Jacobowitz]

On Thu, Mar 18, 2010 at 03:06:15PM +0100, André Pönitz wrote:
> This means a 'next' effectively jumps over two lines, which is rather nasty.
> So I have been removing this optimization in gdb for a while (as the stub 
> is not under my control) without experiencing any bad side effects. Most
> notably, stepping over  for (;;) does not seem to be affected at all.

It's not an "optimization" - it's to improve the user experience, not
to improve performance.

> I dug a bit in gdb's history, and the code is older than anything I could 
> access, i.e. before 1991 or so.  Together with the comment "That is said 
> to make things like for (;;) statements work better" one might get the 
> impression that it was a workaround for some particular compiler or such.
> 
> Does anybody happen to remember what triggered the inclusion of this
> optimization into gdb code?

I certainly don't remember, but I can make an educated guess.  It
depends how your compiler lays out for loops.  If the
condition on the for statement is adjacent to the initial operation:

  for-init
  for-cond
  loop-body
  for-increment
  unconditional branch to for-cond

Then stepping past the last line in loop-body will take you to the
middle of the "line" containing all of init, cond, and increment.

I don't think that's how GCC lays out loops nowadays, I think it's
more:

  for-init
  branch-forwards-to-cond
  loop-body
  for-increment
  for-cond

Whether the current behavior matters in practice, there I have no
idea.

One thing I've found helpful is to diff gdb testsuite log files with
such a change; the diff is noisy, but you can see if there was any
meaningful impact.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Getting pissed off by gdb. Please help with stepping in.

[André Pönitz]

On Thursday 18 March 2010 15:13:38 Daniel Jacobowitz wrote:
> On Thu, Mar 18, 2010 at 03:06:15PM +0100, André Pönitz wrote:
> > This means a 'next' effectively jumps over two lines, which is rather nasty.
> > So I have been removing this optimization in gdb for a while (as the stub 
> > is not under my control) without experiencing any bad side effects. Most
> > notably, stepping over  for (;;) does not seem to be affected at all.
> 
> It's not an "optimization" - it's to improve the user experience, not
> to improve performance.

I used the term from the comment 

  "Optimize by setting the stepping range to the line."

For me it's in fact the opposite to an optimization as the single stepping 
through the rest of the second line leads to one round trip through the 
stub for each of the remaining instructions which easily sums up to a
couple of seconds for lines that generate a hundred instructions.

> > I dug a bit in gdb's history, and the code is older than anything I could 
> > access, i.e. before 1991 or so.  Together with the comment "That is said 
> > to make things like for (;;) statements work better" one might get the 
> > impression that it was a workaround for some particular compiler or such.
> > 
> > Does anybody happen to remember what triggered the inclusion of this
> > optimization into gdb code?
> 
> I certainly don't remember, but I can make an educated guess.  It
> depends how your compiler lays out for loops.  If the
> condition on the for statement is adjacent to the initial operation:
> 
>   for-init
>   for-cond
>   loop-body
>   for-increment
>   unconditional branch to for-cond
> 
> Then stepping past the last line in loop-body will take you to the
> middle of the "line" containing all of init, cond, and increment.
> 
> I don't think that's how GCC lays out loops nowadays, I think it's
> more:
> 
>   for-init
>   branch-forwards-to-cond
>   loop-body
>   for-increment
>   for-cond

I see. Thanks for the explanation.

> Whether the current behavior matters in practice, there I have no
> idea.
> 
> One thing I've found helpful is to diff gdb testsuite log files with
> such a change; the diff is noisy, but you can see if there was any
> meaningful impact.

I'll do that.

Andre'

Re: Getting pissed off by gdb. Please help with stepping in.

[Daniel Jacobowitz]

On Thu, Mar 18, 2010 at 03:33:05PM +0100, André Pönitz wrote:
> I used the term from the comment 
> 
>   "Optimize by setting the stepping range to the line."

Oh, I see - that's the comment below, not the one quoted.  OK.

> For me it's in fact the opposite to an optimization as the single stepping 
> through the rest of the second line leads to one round trip through the 
> stub for each of the remaining instructions which easily sums up to a
> couple of seconds for lines that generate a hundred instructions.

Just what are you disabling then?  I thought it was the if block you
quoted, not the step range changes.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Getting pissed off by gdb. Please help with stepping in.

[André Pönitz]

On Thursday 18 March 2010 15:39:23 Daniel Jacobowitz wrote:
> On Thu, Mar 18, 2010 at 03:33:05PM +0100, André Pönitz wrote:
> > I used the term from the comment 
> > 
> >   "Optimize by setting the stepping range to the line."
> 
> Oh, I see - that's the comment below, not the one quoted.  OK.
> 
> > For me it's in fact the opposite to an optimization as the single stepping 
> > through the rest of the second line leads to one round trip through the 
> > stub for each of the remaining instructions which easily sums up to a
> > couple of seconds for lines that generate a hundred instructions.
> 
> Just what are you disabling then?  I thought it was the if block you
> quoted, not the step range changes.

I am unconditionally executing 

    if (1) {
      /* ... */
      if (debug_infrun)
         fprintf_unfiltered (gdb_stdlog, "infrun: stepped to a different line\n");
      ecs->event_thread->stop_step = 1;
      print_stop_reason (END_STEPPING_RANGE, 0);
      stop_stepping (ecs);
      return;
    }

This means the PC might indeed end up in the middle of a line, and a few
instruction of this line have already been executed. However in these 
somewhat "special" circumstances this is a significantly lesser evil then
skipping a whole line (and taking several seconds for that ;-})

Andre'

Re: Getting pissed off by gdb. Please help with stepping in.

[Doug Evans]

On Thu, Mar 18, 2010 at 6:33 AM, Daniel Jacobowitz <dan@codesourcery.com> wrote:
> here's the previous block:
>
>  if ((stop_pc == stop_pc_sal.pc)
>      && (ecs->event_thread->current_line != stop_pc_sal.line
>          || ecs->event_thread->current_symtab != stop_pc_sal.symtab))
>    {
>      /* We are at the start of a different line.  So stop.  Note that
>         we don't stop if we step into the middle of a different line.
>         That is said to make things like for (;;) statements work
>         better.  */
>
> IOW, if we are at a line boundary, we stop stepping.  If we've ended
> up in the middle of a line, we keep going.  This prevents us from
> ending up in a weird state where we show the line containing the
> function call, but the function has already been called.  I think it'd
> be even more confusing.
>
> This is a difference between stepping out of a function and finishing.

I realize one can *have* that difference.
However, I've rarely (if ever) *wanted* that difference.
But that's just *my* preference, YMMV :-).

Re: Getting pissed off by gdb. Please help with stepping in.

[Michael Snyder]

Doug Evans wrote:

> I agree it should work as you expect.  I don't see the step out of bar
> continuing passed foo, but I do see it stepping into foo (as if you
> had done two steps, so to speak: step out of bar and step into foo).
> [This is with gdb 7.0 and cvs head.]
> One *could* use `finish' to accomplish what you want but I think a
> `step' at the end of the function should behave like `finish' (modulo
> printing the return value of course).
> 

This was discussed a few years ago.  I think it used to work the way
you (doug) expect, but some people thought it should work the way it
does now.

If I'm not mistaken, there's a user settable mode variable that will
set it back to the way it used to behave, but don't ask me to
remember what it is called.

Re: Getting pissed off by gdb. Please help with stepping in.

[temp]

Thanks for all the replies. I see different people have reasons for
different behaviour. If it helps let me tell what I'd like to see.

If I'm inside bar than when I do finish I want to get out of bar and
remain on  'foo( bar() )'. If I keep hitting next or step I should
eventually get out of bar and remain on 'foo( bar() )'. Rationale: when
I'm done with bar debugging I want to have a choice: either to be able to
go into foo or, if I'm not interested in foo, step over it.

If I'm on the line 'foo( bar() )' I would like to have 2 options (this
applies to both gdb and microsoft debugggers). Either step into bar
(existing behaviour) or step over all calls used in arguments and step
right into foo (this isn't supported, isn't it?). Rationale: if call to
foo looks like 'foo( bar1(), bar2(), bar2(), bar4() )' and I'm not
interested in all these bars I need an option to that will be most
productive for this case: go directly inside foo.

Pavel