From: Eli Zaretskii <eliz@gnu.org>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: read watchpoints don't work on targets that support read watchpoints
Date: Mon, 22 Feb 2010 19:24:00 -0000 [thread overview]
Message-ID: <83r5odm5un.fsf@gnu.org> (raw)
In-Reply-To: <201002212147.44779.pedro@codesourcery.com>
> From: Pedro Alves <pedro@codesourcery.com>
> Date: Sun, 21 Feb 2010 21:47:44 +0000
>
> I think we're on the right track, but the logic can
> be simplified further:
>
> If we're watchpoint the memory for both reads and writes, then
> apply the only-if-changed logic. Otherwise, report the watchpoint
> unconditionally. The former can happen either when the user set an
> access or write watchpoint at the same memory as the read
> watchpoint, or, when GDB falls back to emulating read watchpoints
> with access watchpoints.
Agreed.
> WDYT?
I like it, but I have a few comments and questions:
> + /* If trying to set a read-watchpoint, and it turns out it's not
> + supported, try emulating one with an access watchpoint. */
> + if (val == 1 && bpt->watchpoint_type == hw_read)
> + {
> + struct bp_location *loc, **loc_temp;
> +
> + /* But don't try to insert it, if there's already another
> + hw_access location that would be considered a duplicate
> + of this one. */
What does the last comment above mean for the use-case where I set a
read watchpoint and an access watchpoint at the same address (but with
different conditions)? I probably am missing something, because the
above seems to say this use will be impossible?
> + if (bl->watchpoint_type == hw_read)
> + {
> + CORE_ADDR addr;
> + int res;
> +
> + /* A real read watchpoint. Check if we're also
> + trapping the same memory for writes. */
> +
> + res = target_stopped_data_address (¤t_target,
> + &addr);
> + /* We can only find a read watchpoint triggering
> + if we know the address that trapped. We
> + shouldn't get here otherwise. */
> + gdb_assert (res);
> +
> + ALL_BREAKPOINTS (b)
> + if (breakpoint_enabled (b)
> + && (b->type == bp_hardware_watchpoint
> + || b->type == bp_access_watchpoint))
Why do you need to scan ALL_BREAKPOINTS HERE? Can't you scan only the
list returned by watchpoints_triggered?
> + /* Exact match not required. Within range
> + is sufficient. */
> + for (loc = b->loc; loc; loc = loc->next)
> + if (target_watchpoint_addr_within_range
> + (¤t_target,
> + addr,
> + loc->address,
> + loc->length))
And why are we checking watchpoints that couldn't have triggered,
because they watch a different, albeit close, address? What would be
the use-case where such a watchpoint could be relevant to deciding
which watchpoint to announce?
next prev parent reply other threads:[~2010-02-22 19:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-18 1:11 Pedro Alves
2010-02-18 18:41 ` Eli Zaretskii
2010-02-19 10:19 ` Eli Zaretskii
2010-02-21 21:47 ` Pedro Alves
2010-02-22 19:24 ` Eli Zaretskii [this message]
2010-02-22 20:09 ` Pedro Alves
2010-02-22 20:12 ` Pedro Alves
2010-02-22 21:12 ` Eli Zaretskii
2010-02-22 23:39 ` Pedro Alves
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=83r5odm5un.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=pedro@codesourcery.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