Following up on:
 http://sourceware.org/ml/gdb-patches/2008-12/msg00100.html

Here goes.  This addresses this valid use case:

< stopped at 0x1234, thread 1, (stop_pc == 0x1234) >
 (gdb) set $pc = 0xf00
 (gdb) step

GDB at this point would set the stepping range based on the
function at 0x1234, but execution was about to resume at 0xf00.

GDB should instead be setting the stepping range from the
function at 0xf00.

I think it's obvious after the discussion, but I'd still like to
have your approval.  OK?  Any objections?

On Friday 05 December 2008 19:06:14, Pedro Alves wrote:
> On Friday 05 December 2008 18:42:45, Ulrich Weigand wrote:
> > Pedro Alves wrote:
> > 
> > > > > > <stopped at 0x1234, thread 1>
> > > > > >  (gdb) set $pc = 0xf00
> > > > > >  (gdb) call func()
> > > > > 
> > > > > Huh.  But that case is in fact *broken*, because GDB will use stop_pc
> > > > > incorrectly: for example, the check whether we are about to continue
> > > > > at a breakpoint will look at stop_pc, but then continue at $pc.  
> > > > 
> > > > This one I believe was the original intention.  The rationale being
> > > > that you'd not want to hit a breakpoint again at stop_pc (0x1234),
> > > > because there's where you stopped; but, you'd want to hit a a breakpoint
> > > > at 0xf00, sort of like jump *$pc hits a breakpoint at $pc.
> > > > 
> > > > Note, I'm not saying I agree with this.  I did say that probably nobody
> > > > would notice if we got rid of stop_pc.
> > 
> > OK, I see.  This is a valid use case, and it may make sense to keep it.
> > However, as you point out, to make this really work as intended, we'd
> > have make stop_pc a per-thread variable.
> > 
> > And even in that case, the uses of stop_pc in step_1 and step_once seem
> > invalid to me.
> > 
> 
> 100% Agreed.  I'll take care of it.

-- 
Pedro Alves