From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1588 invoked by alias); 5 May 2004 13:44:42 -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 1568 invoked from network); 5 May 2004 13:44:40 -0000 Received: from unknown (HELO sadr.equallogic.com) (66.155.203.134) by sources.redhat.com with SMTP; 5 May 2004 13:44:40 -0000 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i45DiaZh006280 for ; Wed, 5 May 2004 09:44:39 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i45DiZnC006275; Wed, 5 May 2004 09:44:35 -0400 Received: from PKONING.equallogic.com ([172.16.1.103]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 5 May 2004 09:44:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16536.61374.770000.659411@gargle.gargle.HOWL> Date: Wed, 05 May 2004 13:44:00 -0000 From: Paul Koning To: weigand@i1.informatik.uni-erlangen.de Cc: orjan.friberg@axis.com, kettenis@chello.nl, gdb-patches@sources.redhat.com, eliz@gnu.org, drow@false.org Subject: Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT References: <200405042208.AAA07379@faui1d.informatik.uni-erlangen.de> X-OriginalArrivalTime: 05 May 2004 13:44:35.0509 (UTC) FILETIME=[1A484E50:01C432A7] X-SW-Source: 2004-05/txt/msg00134.txt.bz2 >>>>> "Ulrich" == Ulrich Weigand writes: Ulrich> Mark Kettenis wrote: >> 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. Ulrich> The patch also breaks s390(x), for exactly this reason. Ulrich> We don't define target_stopped_data_address, and *cannot* do Ulrich> so because the hardware doesn't provide this information. Neither does MIPS, unless you disassemble the trapping instruction to deduce the address. That's what I've done in our MIPS remote gdb stub. Ulrich> We do know whether a SIGTRAP was due to a (any) watchpoint or Ulrich> not, however, and define STOPPED_BY_WATCHPOINT to indicate Ulrich> this. Ulrich> (Since the hardware supports only write watchpoints, not read Ulrich> or access watchpoints, this should -and used to- be enough Ulrich> for gdb to find out what happened by manually checking Ulrich> watchpoint values.) My experience was that the old code worked if you had only a watchpoint active, but it would produce the wrong results if you had both watchpoints and breakpoints active. The reason was that the scan for matching break/watch points would conclude that the target break had happened due to a non-matching watchpoint and would proceed, rather than break. Ulrich> The patch below uses STOPPED_BY_WATCHPOINT instead of Ulrich> target_stopped_data_address in bpstat_stop_status; this get Ulrich> s390(x) watchpoints back functional. My memory is a little faded by now, but I think I tried that at first. The trouble I ran into is that this doesn't work because (on remote target support for MIPS anyway) the watchpoint handling does an effective "stepi" after the watchpoint stop. After that stepi, stopped_by_watchpoint() would return false because the most recent stop was due to a break (the stepi). That's why remote_stopped_data_address still returns non-zero if stepped_after_stopped_by_watchpoint is set. There may well be a better way to do this, but this is the reason why I did it this way, as far as I can reconstruct it now. Ulrich> Alternatively, we could also make the Ulrich> target_stopped_data_address check only for read and access Ulrich> watch points, *not* for write watchpoints ... That doesn't seem like a good idea. Why would it be reasonable to treat the two differently? paul