From: "Eli Zaretskii" <eliz@gnu.org>
To: GDB <gdb@sources.redhat.com>
Subject: Re: [mi] watchpoint-scope exec async command
Date: Thu, 31 Mar 2005 19:49:00 -0000 [thread overview]
Message-ID: <01c5362a$Blat.v2.4$687ee480@zahav.net.il> (raw)
In-Reply-To: <20050331045426.GA12661@nevyn.them.org> (message from Daniel Jacobowitz on Wed, 30 Mar 2005 23:54:26 -0500)
> Date: Wed, 30 Mar 2005 23:54:26 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: GDB <gdb@sources.redhat.com>
>
> Creating it is easy. Handling it when it goes out of scope, however,
> is harder - if the next thing to trigger a stop is the watchpoint, and
> we discover there that it has gone out of scope. I don't know, this
> may just work.
I think it already works -- see watchpoint_check and insert_bp_location.
> But it feels more complicated to me, for whatever that's worth.
I don't mind using the second alternative.
> > > The second alternative is to treat scope breakpoints specially in
> > > breakpoint_auto_delete: when we see a scope breakpoint that is marked
> > > for deletion, we will have to find its watchpoint, and if that
> > > watchpoint is a hardware watchpoint, we will have to delete that
> > > watchpoint as well.
>
> You said "if that watchpoint is a hardware watchpoint". I'm just
> suggesting treating software watchpoints the same way.
For that, someone will have either to explain why software watchpoints
don't cause the crash with the current code, or make very sure that
making that change for software watchpoints doesn't break them.
next prev parent reply other threads:[~2005-03-31 19:49 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-25 16:12 Bob Rossi
2005-03-25 16:25 ` gdbserver question james osburn
2005-03-25 16:33 ` Daniel Jacobowitz
2005-03-26 13:27 ` [mi] watchpoint-scope exec async command Eli Zaretskii
2005-03-26 13:44 ` Bob Rossi
2005-03-27 14:10 ` Bob Rossi
2005-03-28 21:57 ` Bob Rossi
2005-03-28 22:40 ` Daniel Jacobowitz
2005-03-28 22:54 ` Bob Rossi
2005-03-28 22:59 ` Daniel Jacobowitz
2005-03-29 0:43 ` Bob Rossi
2005-03-29 1:35 ` Daniel Jacobowitz
2005-03-29 1:51 ` Bob Rossi
2005-03-29 2:00 ` Daniel Jacobowitz
2005-03-29 21:33 ` Eli Zaretskii
2005-03-29 21:39 ` Mark Kettenis
2005-03-29 21:47 ` Bob Rossi
2005-03-30 5:15 ` Eli Zaretskii
2005-03-29 21:43 ` Daniel Jacobowitz
2005-03-30 20:10 ` Eli Zaretskii
2005-03-31 0:49 ` Bob Rossi
2005-03-31 4:43 ` Eli Zaretskii
2005-03-31 19:59 ` Bob Rossi
2005-04-01 8:10 ` Eli Zaretskii
2005-04-01 14:09 ` Daniel Jacobowitz
2005-04-02 9:54 ` Eli Zaretskii
2005-04-06 2:13 ` Bob Rossi
2005-04-06 3:51 ` Eli Zaretskii
2005-03-31 2:32 ` Daniel Jacobowitz
2005-03-31 4:48 ` Eli Zaretskii
2005-03-31 6:00 ` Daniel Jacobowitz
2005-03-31 19:49 ` Eli Zaretskii [this message]
2005-03-29 23:29 ` Bob Rossi
2005-03-30 5:12 ` Eli Zaretskii
2005-03-30 0:29 ` Bob Rossi
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='01c5362a$Blat.v2.4$687ee480@zahav.net.il' \
--to=eliz@gnu.org \
--cc=gdb@sources.redhat.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