From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23205 invoked by alias); 1 May 2004 21:18:30 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 23163 invoked from network); 1 May 2004 21:18:27 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.77.109) by sources.redhat.com with SMTP; 1 May 2004 21:18:27 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i41LHgLZ000719; Sat, 1 May 2004 23:17:42 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i41LHgZE001295; Sat, 1 May 2004 23:17:42 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id i41LHZSR001291; Sat, 1 May 2004 23:17:35 +0200 (CEST) Date: Sat, 01 May 2004 21:18:00 -0000 Message-Id: <200405012117.i41LHZSR001291@elgar.kettenis.dyndns.org> From: Mark Kettenis To: orjan.friberg@axis.com CC: gdb-patches@sources.redhat.com, eliz@gnu.org, drow@false.org In-reply-to: <4087DFB6.1030801@axis.com> (message from Orjan Friberg on Thu, 22 Apr 2004 17:07:34 +0200) Subject: Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT References: <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> X-SW-Source: 2004-05/txt/msg00040.txt.bz2 Date: Thu, 22 Apr 2004 17:07:34 +0200 From: Orjan Friberg 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 From Paul Koning : * 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