From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10017 invoked by alias); 6 Apr 2002 17:21:55 -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 10009 invoked from network); 6 Apr 2002 17:21:53 -0000 Received: from unknown (HELO odin.inter.net.il) (192.114.186.10) by sources.redhat.com with SMTP; 6 Apr 2002 17:21:53 -0000 Received: from zaretsky (diup-216-16.inter.net.il [213.8.216.16]) by odin.inter.net.il (Mirapoint Messaging Server MOS 2.9.3.2) with ESMTP id AAQ85342; Sat, 6 Apr 2002 20:21:46 +0300 (IDT) Date: Sat, 06 Apr 2002 09:21:00 -0000 From: "Eli Zaretskii" To: drow@mvista.com Message-Id: <2950-Sat06Apr2002201725+0300-eliz@is.elta.co.il> CC: gdb-patches@sources.redhat.com In-reply-to: <20020406103621.A12359@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 6 Apr 2002 10:36:21 -0500) Subject: Re: [RFA] Fix watchpoints when stepping over a breakpoint Reply-to: Eli Zaretskii 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> X-SW-Source: 2002-04/txt/msg00222.txt.bz2 > Date: Sat, 6 Apr 2002 10:36:21 -0500 > From: Daniel Jacobowitz > > > > Try using a hardware-assisted breakpoint, not a normal breakpoint. > > Since the latter works by replacing the instruction with a breakpoint > > opcode, you cannot have a breakpoint and a watchpoint at exactly the > > same PC value, because doing so replaces the instruction that's > > supposed to write into some data with the breakpoint opcode. > > You can't anyway. You break before an instruction is executed and > watchpoint before the next instruction is executed, right? On x86, yes. But the question what does GDB do when the watchpoint fires remains anyway. GDB should report the watchpoint, not the breakpoint. > > 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? > 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. > 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.