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

[Vladimir Prus <ghost at cs dot msu dot su>]

Michael Snyder wrote:

> 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?

Sure, I'll test it on arm, which uses software single step. Given
that Ulrich reports software single step breakage from my other
patch, it seems like software single step is an important variable
that I did not test :-(

Thanks,
Volodya