From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9815 invoked by alias); 2 May 2004 04:48:07 -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 9808 invoked from network); 2 May 2004 04:48:06 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 2 May 2004 04:48:06 -0000 Received: from [207.232.27.5] (helo=WST0054) by monty-python.gnu.org with asmtp (Exim 4.30) id 1BK8t1-0007UE-RF; Sun, 02 May 2004 00:47:32 -0400 Date: Sun, 02 May 2004 04:48:00 -0000 Message-Id: From: Eli Zaretskii To: Mark Kettenis CC: orjan.friberg@axis.com, gdb-patches@sources.redhat.com,drow@false.org In-reply-to: <200405012117.i41LHZSR001291@elgar.kettenis.dyndns.org> (message from Mark Kettenis on Sat, 1 May 2004 23:17:35 +0200 (CEST)) Subject: Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT Reply-to: Eli Zaretskii 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> <200405012117.i41LHZSR001291@elgar.kettenis.dyndns.org> X-SW-Source: 2004-05/txt/msg00042.txt.bz2 > Date: Sat, 1 May 2004 23:17:35 +0200 (CEST) > From: Mark Kettenis > > 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 Then how do hardware watchpoints work on those systems? IIRC, without a functional target_stopped_data_address, hardware watchpoints would not really work, except by chance and only in simple cases. For example, multiple watchpoints at the same address will not DTRT. > 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. Agreed. > Any people interested in makeing a proposal? I could try, but I need help: I need to know how hardware watchpoints work on supported platforms, including remote ones. If global and area maintainers could describe that for systems they know, I will try to come up with a proposal.