Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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 (&current_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
> +				  (&current_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?


  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