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
next prev 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