Faster stepping amidst breakpoints

[Maxim Grigoriev]

On 01/30/2011 08:49 PM, Joel Brobecker wrote:
>> Consider "set breakpoint always-inserted".
>> I've been wondering lately if we should flip the default.
>>      
> I like the idea of changing the default.
>
> Do you know what the risks would be?  I looked at the code, and
> there isn't something obvious/delicate, it seems.  Perhaps we might
> find ourselves forgetting to re-insert breakpoints, or inserting
> them twice? I think you guys have more experience than we do?
>
> In terms of when, perhaps a good time to switch would be either
> now (about 3 weeks away from planned 7.3 branching), or in 3 weeks
> from now, right after branching.
>    
I have Three observations.

1) I think changing the default is a good idea, when it's proven safe.

I tested it on Xtensa GDB 7.1, which is probably not
as valuable as testing results you are waiting for.

With the default changed to always-inserted == on
and the target understanding z/Z-packets, I observe
a regression :

(gdb) FAIL: gdb.base/break.exp: finish from called function
(gdb) FAIL: gdb.base/callfuncs.exp: finish from call dummy breakpoint 
returns correct value
FAIL: gdb.base/callfuncs.exp: finish after stop in call dummy preserves 
register contents
FAIL: gdb.base/callfuncs.exp: return after stop in call dummy preserves 
register contents
(gdb) FAIL: gdb.base/callfuncs.exp: Finish from nested call level 4
(gdb) FAIL: gdb.base/callfuncs.exp: backtrace after finish from nested 
call level 4
(gdb) FAIL: gdb.base/callfuncs.exp: Finish from nested call level 3
(gdb) FAIL: gdb.base/callfuncs.exp: backtrace after finish from nested 
call level 3
(gdb) FAIL: gdb.base/callfuncs.exp: Finish from nested call level 2
(gdb) FAIL: gdb.base/callfuncs.exp: backtrace after finish from nested 
call level 2
(gdb) FAIL: gdb.base/callfuncs.exp: Finish from nested call level 1
FAIL: gdb.base/callfuncs.exp: nested call dummies preserve register contents
(gdb) FAIL: gdb.base/sepdebug.exp: finish from called function

All new failures were caused by attempting to remove
non-existent breakpoint.


2) I think in the embedded-system world it does matter
     when crashing / detaching GDB leaves target memory
     and/or registers changed.


3) In my original question I was talking about possible GDB
     protocol extensions introducing a concept of a "smart"
     target agent ( if such a term is appropriate here ).

What I meant was a target agent, which can

     -- realize it's about to single-step over an inserted
        breakpoint and then handle it properly ;

     -- watch out for shutting-down GDB communications,
        while counting time-outs, and then return target to the
        reliable state essentially making GDB non-intrusive.

If such functionality existed GDB would be able to discover
that the target agent is "smart" and then safely switch to the
breakpoint-always-inserted==on mode even when it's used
in the embedded system environment.

-- Maxim