From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3156 invoked by alias); 7 May 2003 18:33:32 -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 3145 invoked from network); 7 May 2003 18:33:31 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 7 May 2003 18:33:31 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h47IXVH07931 for ; Wed, 7 May 2003 14:33:31 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h47IXVI17677; Wed, 7 May 2003 14:33:31 -0400 Received: from deneb.localdomain (msalter.cipe.redhat.com [10.0.0.36]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h47IXVj13165; Wed, 7 May 2003 14:33:31 -0400 Received: by deneb.localdomain (Postfix, from userid 500) id 88D0B7885A; Wed, 7 May 2003 14:33:29 -0400 (EDT) From: Mark Salter To: pkoning@equallogic.com Cc: gdb@sources.redhat.com In-reply-to: <16057.18767.270168.635955@pkoning.dev.equallogic.com> (message from Paul Koning on Wed, 7 May 2003 13:58:39 -0400) Subject: Re: watchpoint troubles References: <16057.18767.270168.635955@pkoning.dev.equallogic.com> Message-Id: <20030507183329.88D0B7885A@deneb.localdomain> Date: Wed, 07 May 2003 18:33:00 -0000 X-SW-Source: 2003-05/txt/msg00092.txt.bz2 >>>>> 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. ... > 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? This has come up before: http://sources.redhat.com/ml/gdb-patches/2001-03/msg00506.html I think the answer is that the stub should disable watchpoints anytime the target stops and reenable them when stepping or continuing. --Mark