From: "J.T. Conklin" <jtc@redbacknetworks.com>
To: Stan Shebs <shebs@cygnus.com>
Cc: gdb@cygnus.com
Subject: Re: Any way to avoid inserting & removing breakpoints?
Date: Fri, 18 Dec 1998 11:15:00 -0000 [thread overview]
Message-ID: <199812181915.LAA09147@jtc.redbacknetworks.com> (raw)
In-Reply-To: <xdaf0m9qnx.fsf@andros.cygnus.com>
> jtc@RedBackNetworks.com (J.T. Conklin) writes:
> > I finished my breakpoint extensions prototype, and discovered that GDB
> > inserts all enabled breakpoints when program execution is resumed, and
> > removes them when it regains control.
>
> Yes, this is a "feature". It's pretty well wired into GDB. It might
> be possible to make insert_breakpoints() and remove_breakpoints() do
> some sort of caching-like thing, but I'm not sure that all target
> memory reads know about substituting original code, so you might get
> punished when you're doing disassembly or prologue analysis.
You're right, target memory reads don't know about substituting the
original code. I got around that problem by having my stub restore
memory before control is returned to GDB and to (re-)insert break-
points just before program execution resumes.
I haven't investigated, but it's conceivable that some ROM monitors do
the same thing (for much the same reasons --- simplifying internal
disassembly). If GDB was extended to avoid inserting and removing
breakpoints, it could only be used on targets that manage breakpoints
in this manner.
--jtc
--
J.T. Conklin
RedBack Networks
next prev parent reply other threads:[~1998-12-18 11:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <199812150126.RAA24778.cygnus.gdb@jtc.redbacknetworks.com>
1998-12-17 17:39 ` Stan Shebs
1998-12-17 20:40 ` Todd Whitesel
1998-12-18 11:15 ` J.T. Conklin [this message]
1998-12-14 17:26 J.T. Conklin
1998-12-17 19:20 ` Todd Whitesel
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=199812181915.LAA09147@jtc.redbacknetworks.com \
--to=jtc@redbacknetworks.com \
--cc=gdb@cygnus.com \
--cc=shebs@cygnus.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