This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Faster stepping amidst breakpoints


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






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]