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

[André Pönitz <andre dot poenitz at nokia dot com>]

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'