From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19197 invoked by alias); 28 May 2003 19:54:48 -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 19190 invoked from network); 28 May 2003 19:54:47 -0000 Received: from unknown (HELO aragorn.inter.net.il) (192.114.186.23) by sources.redhat.com with SMTP; 28 May 2003 19:54:47 -0000 Received: from zaretsky (tony08-232-64.inter.net.il [80.230.232.64] (may be forged)) by aragorn.inter.net.il (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ASK86896; Wed, 28 May 2003 22:54:09 +0300 (IDT) Date: Wed, 28 May 2003 19:54:00 -0000 From: "Eli Zaretskii" To: pkoning@equallogic.com Message-Id: <1659-Wed28May2003225524+0300-eliz@elta.co.il> CC: gdb-patches@sources.redhat.com In-reply-to: <16084.56661.295275.544414@pkoning.dev.equallogic.com> (message from Paul Koning on Wed, 28 May 2003 12:01:25 -0400) Subject: Re: proposed PATCH: make watchpoints work correctly Reply-to: Eli Zaretskii References: <16084.56661.295275.544414@pkoning.dev.equallogic.com> X-SW-Source: 2003-05/txt/msg00513.txt.bz2 > Date: Wed, 28 May 2003 12:01:25 -0400 > From: Paul Koning > > If HAVE_NONSTEPPABLE_WATCHPOINT is defined, watchpoints would not stop > for several reasons. First of all, remote.c would return 0 rather > than the watch address after the single step past the instruction > where the watch trap occurred. (Changes to infrun.c, remote.c) > Second, even after that is fixed, bpstat_stop_status wouldn't match > the watchpoint because removing the watchpoint (to single step) > deleted the valchain which is used to do the matching (Change to > breakpoint.c) > > If a watchpoint is defined, but the program stops for some other > reason -- either a breakpoint, or a break instruction hardcoded in the > target code -- bpstat_stop_status would encounter the watchpoint in > its scan for possible reasons. It would take no action on it but > leave its "stop" and "print" bits set so you would see the stop > reported as if it were a watchpoint hit. Also, a "next" or "step" > command would act as "stepi", i.e., stop after every instruction. > (Changes to breakpoint.c). (It's been a while since I hacked on watchpoint-related code, so I apologize in advance for asking possibly dumb questions.) The above description made me nervous: it almost sounds like the current watchpoint support is pretty much dysfunctional, as most of the changes you suggest are not specific neither to remote.c nor to HAVE_NONSTEPPABLE_WATCHPOINT. So could you please explain how, given those deficiencies, watchpoints do work for native targets such as x86, but did not work for your target?