From: Maxim Grigoriev <maxim@tensilica.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
Marc Gauthier <marc@tensilica.com>,
Maxim Grigoriev <maxim@mail.tensilica.com>
Subject: Re: Faster stepping amidst breakpoints
Date: Thu, 03 Feb 2011 22:54:00 -0000 [thread overview]
Message-ID: <4D4B31F4.7040407@tensilica.com> (raw)
In-Reply-To: <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
next prev parent reply other threads:[~2011-02-03 22:54 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-22 15:06 Maxim Grigoriev
2011-01-24 8:04 ` Daniel Jacobowitz
2011-01-24 21:08 ` Maxim Grigoriev
2011-01-31 7:47 ` Joel Brobecker
2011-01-31 15:39 ` Daniel Jacobowitz
2011-02-01 3:23 ` Joel Brobecker
2011-02-01 18:44 ` Michael Snyder
2011-02-03 4:55 ` Joel Brobecker
2011-02-02 17:10 ` Daniel Jacobowitz
2011-02-03 4:46 ` Joel Brobecker
2011-02-13 15:17 ` Mark Kettenis
2011-02-14 3:27 ` Joel Brobecker
2011-02-14 10:50 ` Joel Brobecker
2011-02-01 15:12 ` Pedro Alves
2011-02-03 22:54 ` Maxim Grigoriev [this message]
2011-02-04 16:06 ` Tom Tromey
2011-02-04 19:32 ` Maxim Grigoriev
2011-02-04 16:33 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D4B31F4.7040407@tensilica.com \
--to=maxim@tensilica.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=marc@tensilica.com \
--cc=maxim@mail.tensilica.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).