From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32274 invoked by alias); 7 May 2003 17:59:01 -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 32255 invoked from network); 7 May 2003 17:59:00 -0000 Received: from unknown (HELO cygnus.equallogic.com) (65.170.102.10) by sources.redhat.com with SMTP; 7 May 2003 17:59:00 -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 h47Hx0t04434 for ; Wed, 7 May 2003 13:59:00 -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 h47Hx0r04428 for ; Wed, 7 May 2003 13:59:00 -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 h47HwxI29564 for ; Wed, 7 May 2003 13:58:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16057.18767.270168.635955@pkoning.dev.equallogic.com> Date: Wed, 07 May 2003 17:59:00 -0000 From: Paul Koning To: gdb@sources.redhat.com Subject: watchpoint troubles X-SW-Source: 2003-05/txt/msg00091.txt.bz2 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. In these tests I was using "awatch", i.e., watching both loads and stores. First... I had defined HAVE_NONSTEPPABLE_WATCHPOINT to force gdb to step over the instruction where the watchpoint occurs. That seems to work, but it has a bizarre side effect: Once the watchpoint is defined, every entry to gdb (whether from that watchpoint or from single stepping) prints out a mention of that watchpoint. I tracked it down to bpstat_stop_status, which looks up the watch address. If that comes back from the target code as zero, it continues the breakpoint scan loop ("continue" around line 2637 in breakpoint.c). Since the default settings for a bpstat entry is stop and print, two evil things happen: (a) the watchpoint info is printed (minor), (b) the single-stepping stops immediately, i.e., an "n" command is turned into a "stepi" command! (major). I figured I could fix this by setting stop and print to zero before that continue, but if I do that then gdb doesn't stop at all anymore as soon as I continue from a watchpoint. So, just to try something, I removed the definition of HAVE_NONSTEPPABLE_WATCHPOINT, because it looked like part of the problem is that the "stopped due to a watchpoint" flag is no longer set after the single-step after the watchpoint hits. That exposed a different bug, which is very clear in the remote protocol debug printout. 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? Thanks, paul