From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8486 invoked by alias); 7 May 2003 19:38:33 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8467 invoked from network); 7 May 2003 19:38:33 -0000 Received: from unknown (HELO cygnus.equallogic.com) (65.170.102.10) by sources.redhat.com with SMTP; 7 May 2003 19:38:33 -0000 Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id h47JcWt06977 for ; Wed, 7 May 2003 15:38:32 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id h47JcWr06968; Wed, 7 May 2003 15:38:32 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id h47JcWb06860; Wed, 7 May 2003 15:38:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16057.24739.917676.478545@pkoning.dev.equallogic.com> Date: Wed, 07 May 2003 19:38:00 -0000 From: Paul Koning To: msalter@redhat.com, gdb@sources.redhat.com Subject: Re: watchpoint troubles References: <16057.18767.270168.635955@pkoning.dev.equallogic.com> <20030507183329.88D0B7885A@deneb.localdomain> <16057.22019.173960.269354@pkoning.dev.equallogic.com> X-SW-Source: 2003-05/txt/msg00096.txt.bz2 >>>>> "Paul" == Paul Koning writes: >>>>> "Mark" == Mark Salter writes: >>>>> Paul Koning writes: >>> I'm having all sorts of watchpoint troubles with gdb 5.3 and a >>> remote target. These are things I'm running into as I'm working >>> to improve the implementation of watchpoints in my remote stub. Mark> ... >>> Without that flag, the first thing that gdb does after the >>> watchpoint entry is to read the address being watched. Needless >>> to say, that causes a watchpoint recursion within the target >>> stub. In the case where HAVE_NONSTEPPABLE_WATCHPOINT is defined, >>> things work because the watchpoint is removed before the memory >>> read request is made. >>> Since gdb normally removes and reinserts watch/break points on >>> every entry, I figured it's gdb's job to do things in the right >>> order. Bad assumption? I can certainly hack up the stub to >>> remove the watchpoints before acting on any memory access >>> requests from gdb, but is that kind of hackery supposed to be >>> done? Mark> This has come up before: Mark> http://sources.redhat.com/ml/gdb-patches/2001-03/msg00506.html Mark> I think the answer is that the stub should disable watchpoints Mark> anytime the target stops and reenable them when stepping or Mark> continuing. Paul> Thanks. Paul> I just read that thread and the final message seems to say "gdb Paul> can be fixed to remove the watchpoints before doing the memory Paul> read in the case where HAVE_NONSTEPPABLE_WATCHPOINT is Paul> undefined. Yes, I thought so. Paul> I may do that just to try it. As I mentioned, what I *really* Paul> want is for the case where HAVE_NONSTEPPABLE_WATCHPOINT *is* Paul> defined to work correctly. Right now it doesn't. Ok, so I tried it. The simple approach (call remove_breakpoints before the call to bp_stop_status) doesn't work. And that may be another reason why things won't work even when I do have HAVE_NONSTEPPABLE_WATCHPOINT defined. The problem is that remove_breakpoints for some reason frees the val_chain of the watchpoint. So when bpstat_stop_status looks to see whether the watched address (as reported by the target) matches what we're watching, it says "no" because the watchpoint appears not to be watching anything (because its val_chain is null). So now my watchpoint doesn't stop at all... A similar problem applies in the HAVE_NONSTEPPABLE_WATCHPOINT case, because that's done by calling remove_breakpoints followed by single-stepping the target. So quite apart from the fact that remote.c believes that the last thing that happened was a single step rather than a watchpoint, the val_chain is now gone so it isn't seen in bpstat_stop_status. paul