This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT
- From: Mark Kettenis <kettenis at chello dot nl>
- To: orjan dot friberg at axis dot com
- Cc: gdb-patches at sources dot redhat dot com, eliz at gnu dot org, drow at false dot org
- Date: Sat, 1 May 2004 23:17:35 +0200 (CEST)
- Subject: Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT
- References: <ur81oqb1c.fsf@elta.co.il> <407282F4.2080602@axis.com> <20040406142228.GA29473@nevyn.them.org> <6654-Thu15Apr2004111217+0300-eliz@gnu.org> <407E8CEF.2050007@axis.com> <407FC69A.1000701@axis.com> <1438-Sat17Apr2004112204+0300-eliz@gnu.org> <4083E930.8040005@axis.com> <4087DFB6.1030801@axis.com>
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