From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25256 invoked by alias); 4 May 2004 22:10:22 -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 25247 invoked from network); 4 May 2004 22:10:19 -0000 Received: from unknown (HELO faui10.informatik.uni-erlangen.de) (131.188.31.10) by sources.redhat.com with SMTP; 4 May 2004 22:10:19 -0000 Received: from faui1d.informatik.uni-erlangen.de (faui1d [131.188.31.34]) by faui10.informatik.uni-erlangen.de (8.9.3p3/8.1.9-FAU) with ESMTP id AAA01642; Wed, 5 May 2004 00:08:30 +0200 (CEST) From: Ulrich Weigand Received: (from weigand@localhost) by faui1d.informatik.uni-erlangen.de (8.9.3p3/8.1.6-FAU) id AAA07379; Wed, 5 May 2004 00:08:29 +0200 (CEST) Message-Id: <200405042208.AAA07379@faui1d.informatik.uni-erlangen.de> Subject: Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT To: orjan.friberg@axis.com, kettenis@chello.nl Date: Tue, 04 May 2004 22:10:00 -0000 Cc: gdb-patches@sources.redhat.com, eliz@gnu.org, drow@false.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-05/txt/msg00123.txt.bz2 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. The patch also breaks s390(x), for exactly this reason. We don't define target_stopped_data_address, and *cannot* do so because the hardware doesn't provide this information. We do know whether a SIGTRAP was due to a (any) watchpoint or not, however, and define STOPPED_BY_WATCHPOINT to indicate this. (Since the hardware supports only write watchpoints, not read or access watchpoints, this should -and used to- be enough for gdb to find out what happened by manually checking watchpoint values.) The patch below uses STOPPED_BY_WATCHPOINT instead of target_stopped_data_address in bpstat_stop_status; this get s390(x) watchpoints back functional. Alternatively, we could also make the target_stopped_data_address check only for read and access watch points, *not* for write watchpoints ... What do you think? Index: gdb/breakpoint.c =================================================================== RCS file: /cvs/src/src/gdb/breakpoint.c,v retrieving revision 1.170 diff -c -p -r1.170 breakpoint.c *** gdb/breakpoint.c 2 May 2004 00:21:41 -0000 1.170 --- gdb/breakpoint.c 4 May 2004 21:20:10 -0000 *************** bpstat_stop_status (CORE_ADDR bp_addr, p *** 2631,2637 **** && !((b->type == bp_hardware_watchpoint || b->type == bp_read_watchpoint || b->type == bp_access_watchpoint) ! && target_stopped_data_address () != 0) && b->type != bp_hardware_breakpoint && b->type != bp_catch_fork && b->type != bp_catch_vfork --- 2631,2637 ---- && !((b->type == bp_hardware_watchpoint || b->type == bp_read_watchpoint || b->type == bp_access_watchpoint) ! && STOPPED_BY_WATCHPOINT ()) && b->type != bp_hardware_breakpoint && b->type != bp_catch_fork && b->type != bp_catch_vfork -- Dr. Ulrich Weigand weigand@informatik.uni-erlangen.de