Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@chello.nl>
To: orjan.friberg@axis.com
Cc: gdb-patches@sources.redhat.com, eliz@gnu.org, drow@false.org
Subject: Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT
Date: Sat, 01 May 2004 21:18:00 -0000	[thread overview]
Message-ID: <200405012117.i41LHZSR001291@elgar.kettenis.dyndns.org> (raw)
In-Reply-To: <4087DFB6.1030801@axis.com> (message from Orjan Friberg on Thu, 22 Apr 2004 17:07:34 +0200)

   Date: Thu, 22 Apr 2004 17:07:34 +0200
   From: Orjan Friberg <orjan.friberg@axis.com>

   Orjan Friberg wrote:
   > 
   > Agreed.  I am quite happy to live with your suggested solution, at least 
   > for now.  I certainly don't have the audacity to suggest such changes 
   > should be made to accomodate a target that isn't even submitted yet ;) .

   ... which brings me back to the reason for re-opening this thread:
   getting Paul Koning's patch to make read/access watchpoints work
   when HAVE_NONSTEPPABLE_WATCHPOINT is defined accepted.

   I did change one thing in Paul's patch, which should be
   highlighted: the change in bpstat_stop_status previously applied to
   bp_watchpoint types also (in addition to bp_hardware_watchpoint,
   bp_read_watchpoint, and bp_access_watchpoint), but as far as I can
   tell target_stopped_data_address applies only to hardware-assisted
   watchpoints, not software watchpoints.  Maybe that needs to be made
   more clear in the comment.

   Comments?

This patch breaks hardware watchpoints in SVR4-derived systems.  Those
systems don't provide target_stopped_data_address().  The default
target_stopped_data_address() will always return zero, which means
that triggered watchpoints aren't properly caught.  This results in
spurious SIGTRAPS.

Providing target_stopped_data_address() for the SVR4 proc(4) should be
possible, but its a risky bussiness, since there are several slight
variations of that interface.

   2004-04-22  Orjan Friberg <orjanf@axis.com>

	   From Paul Koning <pkoning@equallogic.com>:
	   * breakpoint.c (free_valchain): New function.
	   (insert_bp_location, delete_breakpoint): Use free_valchain.
	   (remove_breakpoint): Do not remove the valchain.
	   (bpstat_stop_status): If not stopped by watchpoint, skip
	   watchpoints when generating stop status list.
	   * infrun.c (handle_inferior_event): Make
	   stepped_after_stopped_by_watchpoint a global variable.
	   * remote.c (remote_stopped_data_address): Return watch data
	   address rather than zero if stepped_after_stopped_by_watchpoint is
	   set.

Anyway.  The problem is clearly that the whole target-specific
interface for hardware watchpoints is a mess.  We should really try to
*design* a proper interface instead of continuing to tweak the
existing interfaces.  Any people interested in makeing a proposal?

Mark


  parent reply	other threads:[~2004-05-01 21:18 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-08  8:50 Orjan Friberg
2003-10-08 10:26 ` Eli Zaretskii
2003-10-08 13:36   ` Orjan Friberg
2003-10-08 16:02     ` Paul Koning
2004-04-06 10:14   ` Orjan Friberg
2004-04-06 14:22     ` Daniel Jacobowitz
2004-04-07  9:11       ` Orjan Friberg
2004-04-15  8:17       ` Eli Zaretskii
2004-04-15 13:24         ` Orjan Friberg
2004-04-16  7:18           ` Eli Zaretskii
2004-04-16  9:46             ` Orjan Friberg
2004-04-16 11:42           ` Orjan Friberg
2004-04-17  8:27             ` Eli Zaretskii
2004-04-19 14:59               ` Orjan Friberg
2004-04-22 15:08                 ` Orjan Friberg
2004-04-22 15:48                   ` Paul Koning
2004-04-22 18:40                   ` Eli Zaretskii
2004-04-22 19:07                     ` Paul Koning
2004-04-22 19:09                       ` Paul Koning
2004-04-23 18:20                       ` Eli Zaretskii
2004-04-23 18:22                   ` Eli Zaretskii
2004-04-26  9:04                     ` Orjan Friberg
2004-04-26  9:25                       ` Eli Zaretskii
2004-05-01 21:18                   ` Mark Kettenis [this message]
2004-05-02  4:48                     ` Eli Zaretskii
2004-05-03 11:25                       ` Orjan Friberg
2004-05-03 15:05                         ` Andrew Cagney
2004-05-03 18:01                           ` Eli Zaretskii
2004-05-03 18:36                             ` Andrew Cagney
2004-05-03 17:49                         ` Eli Zaretskii
2004-05-04  7:31                           ` Orjan Friberg
2004-05-04 23:52                             ` Daniel Jacobowitz
2004-05-04 22:10 Ulrich Weigand
2004-05-05  5:08 ` Eli Zaretskii
2004-05-05  8:26   ` Orjan Friberg
2004-05-06  4:58     ` Eli Zaretskii
2004-05-06 14:21       ` Daniel Jacobowitz
2004-05-06 18:02         ` Eli Zaretskii
2004-05-06 18:05           ` Daniel Jacobowitz
2004-05-07  8:18             ` Eli Zaretskii
2004-05-06 21:34   ` Ulrich Weigand
2004-05-06 21:36     ` Daniel Jacobowitz
2004-05-07  8:22       ` Eli Zaretskii
2004-05-07  8:23     ` Eli Zaretskii
2004-05-05 13:44 ` Paul Koning
2004-05-06  5:08   ` Eli Zaretskii
2004-05-06 13:44     ` Paul Koning
2004-05-06 21:38   ` Ulrich Weigand
2004-05-06 21:49     ` Paul Koning
2004-05-07  8:18     ` Eli Zaretskii

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=200405012117.i41LHZSR001291@elgar.kettenis.dyndns.org \
    --to=kettenis@chello.nl \
    --cc=drow@false.org \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=orjan.friberg@axis.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