This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Faster stepping amidst breakpoints
- From: Maxim Grigoriev <maxim at tensilica dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, Marc Gauthier <marc at tensilica dot com>, Maxim Grigoriev <maxim at mail dot tensilica dot com>
- Date: Thu, 3 Feb 2011 14:53:40 -0800
- Subject: Re: Faster stepping amidst breakpoints
- References: <4D3A114D.7010301@tensilica.com> <20110123001433.GA6352@caradoc.them.org> <20110131044951.GG2384@adacore.com>
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