From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22960 invoked by alias); 20 Jul 2004 19:37:00 -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 22750 invoked from network); 20 Jul 2004 19:36:53 -0000 Received: from unknown (HELO aragorn.inter.net.il) (192.114.186.23) by sourceware.org with SMTP; 20 Jul 2004 19:36:53 -0000 Received: from zaretski ([80.230.155.169]) by aragorn.inter.net.il (MOS 3.4.6-GR) with ESMTP id DVV14602; Tue, 20 Jul 2004 22:36:44 +0300 (IDT) Date: Tue, 20 Jul 2004 19:37:00 -0000 From: "Eli Zaretskii" To: Orjan Friberg Message-Id: <9787-Tue20Jul2004223539+0300-eliz@gnu.org> CC: gdb-patches@sources.redhat.com In-reply-to: <40FD2E1F.7070403@axis.com> (message from Orjan Friberg on Tue, 20 Jul 2004 16:37:19 +0200) Subject: Re: recurse.exp: watch on local variable that goes out of scope Reply-to: Eli Zaretskii References: <40FD2E1F.7070403@axis.com> X-SW-Source: 2004-07/txt/msg00258.txt.bz2 > Date: Tue, 20 Jul 2004 16:37:19 +0200 > From: Orjan Friberg > > Now for the confusing part: bpstat_stop_status is called with > stopped_by_watchpoint == 1. This is because, at this point, > i386_stopped_data_address returns the address of the local variable "b" (the > address it had in recurse (a=5)), as if it were stopped due to a watchpoint hit. > I would have expected i386_stopped_data_address to return 0 at this point, > since it didn't stop due to a watchpoint hit. What am I missing here? Does > i386_stopped_data_address retain the stopped data address from the previous hit? No, it shouldn't return a stale address, it should return zero. I reproduce the entire source of i386_stopped_data_address below; as you see, it starts by zeroing out `addr' and assigns it a non-zero value _only_ if I386_DR_WATCH_HIT(i) returns non-zero for some value of i. This is supposed to query the debuggee about its debug registers, and assumes that one of the debug registers will show that a watchpoint has been hit only if a watchpoint has indeed been hit. Can you step thru i386_stopped_data_address and see what exactly happens there in your case? CORE_ADDR i386_stopped_data_address (void) { CORE_ADDR addr = 0; int i; dr_status_mirror = I386_DR_LOW_GET_STATUS (); ALL_DEBUG_REGISTERS(i) { if (I386_DR_WATCH_HIT (i) /* This second condition makes sure DRi is set up for a data watchpoint, not a hardware breakpoint. The reason is that GDB doesn't call the target_stopped_data_address method except for data watchpoints. In other words, I'm being paranoiac. */ && I386_DR_GET_RW_LEN (i) != 0) { addr = dr_mirror[i]; if (maint_show_dr) i386_show_dr ("watchpoint_hit", addr, -1, hw_write); } } if (maint_show_dr && addr == 0) i386_show_dr ("stopped_data_addr", 0, 0, hw_write); return addr; }