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

Michael Snyder
2007-11-26T18:51:41Z

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