From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17568 invoked by alias); 6 Apr 2002 17:49:08 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 17561 invoked from network); 6 Apr 2002 17:49:06 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 6 Apr 2002 17:49:06 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16tuJM-0006U1-00; Sat, 06 Apr 2002 12:49:12 -0500 Date: Sat, 06 Apr 2002 09:49:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Fix watchpoints when stepping over a breakpoint Message-ID: <20020406124912.A24394@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , gdb-patches@sources.redhat.com References: <20020402184333.A8464@nevyn.them.org> <6480-Fri05Apr2002103430+0300-eliz@is.elta.co.il> <20020405105416.A14105@nevyn.them.org> <9743-Fri05Apr2002194115+0300-eliz@is.elta.co.il> <20020405120851.A17113@nevyn.them.org> <4331-Sat06Apr2002104144+0300-eliz@is.elta.co.il> <20020406103621.A12359@nevyn.them.org> <2950-Sat06Apr2002201725+0300-eliz@is.elta.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2950-Sat06Apr2002201725+0300-eliz@is.elta.co.il> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00223.txt.bz2 On Sat, Apr 06, 2002 at 08:17:25PM +0300, Eli Zaretskii wrote: > > > If this is limited to stepping, can we check whether we are stepping > > > instead of (or in addition to) the test for whether to ignore > > > breakpoints? > > > > Well, I set the ignore breakpoints flag in the caller only if we are > > stepping. > > Isn't it better to make bpstat_stop_status test for stepping directly? The test I'm using is 'trap_expected' - well: if (stop_signal == TARGET_SIGNAL_TRAP && trap_expected && through_sigtramp_breakpoint == NULL) It's static to infrun.c, and it describes the precise circumstances in which we want this behavior. We can ignore stop_signal (since we only call bpstat_stop_status if we got a trap), but I have no idea how through_sigtramp_breakpoint works. I'd rather calculate this at the call site than duplicating logic I don't understand very well in breakpoint.c (which has no business knowing about the internals of infrun). > > No. In my original message I made a comment about shlib_event > > breakpoints being a problem. Other breakpoints would to. This is all > > because of the "watchpoint after instr, breakpoint before" thing - we > > would still have to deal with this, or we'd just keep hitting the same > > breakpoint over and over if there was a watchpoint on the next > > instruction. > > Sounds like Andrew was right: the decrement-PC logic is screwed. I agree. It's a rat's nest. > > But something more fundamental is wrong, because we never > > stop -at all-. I remember something involving initializing the > > watchpoint registers... > > I thought that part was solved, but perhaps I'm confused. So did I, but it does not appear to be the case. Even access watchpoints die. At a guess, in the good case: insert_watchpoint (addr=8049574, len=4, type=data-read/write): CONTROL (DR7): 000f0101 STATUS (DR6): ffff4ff1 DR0: addr=0x08049574, ref.count=1 DR1: addr=0x00000000, ref.count=0 DR2: addr=0x00000000, ref.count=0 DR3: addr=0x00000000, ref.count=0 In the bad case: insert_watchpoint (addr=8049574, len=4, type=data-read/write): CONTROL (DR7): 000f0101 STATUS (DR6): ffff4ff0 DR0: addr=0x08049574, ref.count=2 DR1: addr=0x00000000, ref.count=0 DR2: addr=0x00000000, ref.count=0 DR3: addr=0x00000000, ref.count=0 insert_watchpoint (addr=8049574, len=4, type=data-read/write): CONTROL (DR7): 000f0101 STATUS (DR6): ffff4ff0 DR0: addr=0x08049574, ref.count=3 DR1: addr=0x00000000, ref.count=0 DR2: addr=0x00000000, ref.count=0 DR3: addr=0x00000000, ref.count=0 The watchpoint is not removed after program normal exit, and the refcount escalates. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer