From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26764 invoked by alias); 7 May 2003 18:53:13 -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 26744 invoked from network); 7 May 2003 18:53:12 -0000 Received: from unknown (HELO cygnus.equallogic.com) (65.170.102.10) by sources.redhat.com with SMTP; 7 May 2003 18:53:12 -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 h47IrCt06041 for ; Wed, 7 May 2003 14:53:12 -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 h47IrBr06032; Wed, 7 May 2003 14:53:11 -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 h47IrBV02462; Wed, 7 May 2003 14:53:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16057.22019.173960.269354@pkoning.dev.equallogic.com> Date: Wed, 07 May 2003 18:53:00 -0000 From: Paul Koning To: msalter@redhat.com Cc: gdb@sources.redhat.com Subject: Re: watchpoint troubles References: <16057.18767.270168.635955@pkoning.dev.equallogic.com> <20030507183329.88D0B7885A@deneb.localdomain> X-SW-Source: 2003-05/txt/msg00094.txt.bz2 >>>>> "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. Thanks. I just read that thread and the final message seems to say "gdb can be fixed to remove the watchpoints before doing the memory read in the case where HAVE_NONSTEPPABLE_WATCHPOINT is undefined. Yes, I thought so. I may do that just to try it. As I mentioned, what I *really* want is for the case where HAVE_NONSTEPPABLE_WATCHPOINT *is* defined to work correctly. Right now it doesn't. paul