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

[Doug Evans <dje at google dot com>]

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.