From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19492 invoked by alias); 11 Apr 2002 21:15:22 -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 19478 invoked from network); 11 Apr 2002 21:15:18 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 11 Apr 2002 21:15:18 -0000 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id OAA03555; Thu, 11 Apr 2002 14:15:10 -0700 (PDT) Message-ID: <3CB5FA10.139B77AE@redhat.com> Date: Thu, 11 Apr 2002 14:15:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: Doug Evans , gdb@sources.redhat.com Subject: Re: STOPPED_BY_WATCHPOINT peculiarity References: <200204022154.NAA10074@casey.transmeta.com> <20020402170145.A3797@nevyn.them.org> <20020402172008.A4532@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00175.txt.bz2 Daniel Jacobowitz wrote: > > On Tue, Apr 02, 2002 at 05:01:45PM -0500, Daniel Jacobowitz wrote: > > On Tue, Apr 02, 2002 at 01:54:47PM -0800, Doug Evans wrote: > > > Something is not right, or at least confusing, in watchpoint-land. > > > > > > This code in infrun.c is odd: > > > > > > /* It may be possible to simply continue after a watchpoint. */ > > > if (HAVE_CONTINUABLE_WATCHPOINT) > > > STOPPED_BY_WATCHPOINT (ecs->ws); > > > > > > STOPPED_BY_WATCHPOINT is a predicate. > > > Therefore at first glance this code is pointless. > > > > > > Things are slightly less confusing by recognizing that in the > > > process of computing STOPPED_BY_WATCHPOINT some debugging printf's > > > may get printed. e.g. grep for maint_show_dr in > > > i386-nat.c:i386_stopped_data_address. > > > > > > nm-i386.h: > > > #define STOPPED_BY_WATCHPOINT(W) (i386_stopped_data_address () != 0) > > > > > > Is that all there is to it? > > > > > > If so, a comment should be added, maybe something like > > > > > > - /* It may be possible to simply continue after a watchpoint. */ > > > + /* It may be possible to simply continue after a watchpoint. > > > + While at first glance this code is pointless, STOPPED_BY_WATCHPOINT > > > + is called in case there are any maintenance debugging printf's. */ > > > if (HAVE_CONTINUABLE_WATCHPOINT) > > > STOPPED_BY_WATCHPOINT (ecs->ws); > > > > What astonishing timing... I believe there is more going on here, and I > > was in the middle of looking at this code just a moment ago. See the > > test failure on i386-linux in gdb.c++/annota2.exp (watch a.x). We have > > a problem actually correctly detecting that we are stopped by a > > watchpoint. > > Actually, I take that back. STOPPED_BY_WATCHPOINT has nothing to do > with the problem I'm working on. This line came in far enough back > that the public tree's CVS history appears to be useless; it's been > through some reformats but that's it. Might want to ask a Cygnus > person to dig around. Yo! ;-) 1) History: the line was added in 1995 by Jim Kingdon. I can't find any explanation in the changelogs or comments. 2) Yes, it is possible for a predicate to have side effects, and indeed several implementations of this one (eg. sparc) cause a register to be read, and one (ia64) causes a register to be modified. Based on that, I don't think it is safe to remove the line, without much more deliberation.