From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2708 invoked by alias); 6 May 2004 21:34:16 -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 2697 invoked from network); 6 May 2004 21:34:14 -0000 Received: from unknown (HELO faui10.informatik.uni-erlangen.de) (131.188.31.10) by sources.redhat.com with SMTP; 6 May 2004 21:34:14 -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 XAA09084; Thu, 6 May 2004 23:34:10 +0200 (CEST) From: Ulrich Weigand Received: (from weigand@localhost) by faui1d.informatik.uni-erlangen.de (8.9.3p3/8.1.6-FAU) id XAA05759; Thu, 6 May 2004 23:34:10 +0200 (CEST) Message-Id: <200405062134.XAA05759@faui1d.informatik.uni-erlangen.de> Subject: Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT To: eliz@gnu.org Date: Thu, 06 May 2004 21:34:00 -0000 Cc: weigand@i1.informatik.uni-erlangen.de (Ulrich Weigand), orjan.friberg@axis.com, kettenis@chello.nl, gdb-patches@sources.redhat.com, drow@false.org In-Reply-To: from "Eli Zaretskii" at May 05, 2004 08:08:07 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-05/txt/msg00159.txt.bz2 > So the s390(x) has a means of telling that some watchpoint fired, but > there's no way to know which one, is that true? Exactly. > If the hardware supports only write watchpoints, and since you don't > know what address triggered a watchpoint, this would seem to imply > that there's no way of getting awatch and rwatch commands to give > useful results, is that right? Yes. > So what does GDB on the s390 do when the user tries to invoke > awatch or rwatch? It should probably fail; I'll make sure of this ... > > Alternatively, we could also make the target_stopped_data_address > > check only for read and access watch points, *not* for write > > watchpoints ... > > GDB should use the result of target_stopped_data_address to find out > which watchpoints are candidates for being a possible reason for > causing SIGTRAP. GDB doesn't do so right now, but that's because the > hardware watchpoints handling is an incremental modification of the > original code that handled only software watchpoints. Well, the current behaviour of GDB is correct on targets like s390 that cannot implement target_stopped_data_address, while your suggested change would break such targets. May I suggest that your change be implemented conditionally on whether the target supports it? > So right now, target_stopped_data_address is almost an alias for > STOPPED_BY_WATCHPOINT, but it is IMHO wrong to continue this illusion > into the future. Therefore, I like your patch better than the > alternative which would modify target_stopped_data_address. Actually I didn't suggest modifying target_stopped_data_address. I mean something like: 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 6 May 2004 21:31:30 -0000 *************** bpstat_stop_status (CORE_ADDR bp_addr, p *** 2628,2635 **** address). Otherwise gdb won't stop on a break instruction in the code (not from a breakpoint) when a hardware watchpoint has been defined. */ if (b->type != bp_watchpoint ! && !((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 --- 2628,2635 ---- address). Otherwise gdb won't stop on a break instruction in the code (not from a breakpoint) when a hardware watchpoint has been defined. */ if (b->type != bp_watchpoint ! && 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 This simply ensures that target_stopped_data_address is only ever used for read or access watchpoints (where it is in fact required). Targets that don't support it would still be able to support hardware write watchpoints. Bye, Ulrich -- Dr. Ulrich Weigand weigand@informatik.uni-erlangen.de