Re: [RFA] Don't ignore consecutive breakpoints.

[Michael Snyder <msnyder at specifix dot com>]

On Fri, 2007-11-23 at 23:10 +0300, Vladimir Prus wrote:
> Suppose we have two breakpoints at two consecutive
> addresses, and we do "step" while stopped on the
> first breakpoint. GDB testsuite has a test (consecutive.exp)
> that the second breakpoint will be hit a reported, and the

Yeah, I was the author of that test, back in 2001.
Several years and several employers ago, but I think 
I am able to remember a little about the context.

> test passes, but the code directly contradicts, saying:
> 
>       /* Don't even think about breakpoints if just proceeded over a
>          breakpoint.  */
>       if (stop_signal == TARGET_SIGNAL_TRAP && trap_expected)
> 	{
>           if (debug_infrun)
> 	    fprintf_unfiltered (gdb_stdlog, "infrun: trap expected\n");
> 	  bpstat_clear (&stop_bpstat);
> 	}
> 
> what's happening is that we indeed ignore the breakpoint, and try
> to step further. However ecs->another_trap is not set, so we step
> with breakpoints inserted, and immediately hit the now-inserted
> breakpoint. Therefore, I propose to remove that code.
> 
> On x86, the below patch causes a single test outcome change:
> 
> -KFAIL: gdb.base/watchpoint.exp: next after watch x (PRMS: gdb/38)
> +PASS: gdb.base/watchpoint.exp: next after watch x

Yeah, the problem is that you have only tested x86 architecture, 
and what I think I recall is that this test was for software
single-step.

You have to be aware that you have just single-stepped, so that
you interpret the trap instruction under the PC as related to 
stepping.  If you have two consecutive BP-related traps, and you
try to single step over one of them, you may miss the second one
because you believe it to be only a single-stepping trap.

Can you test your patch on an architecture that uses software SS?

Thanks,
Michael