From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3129 invoked by alias); 5 Apr 2002 17:55:33 -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 3121 invoked from network); 5 Apr 2002 17:55:32 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 5 Apr 2002 17:55:32 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 0AF303C9F; Fri, 5 Apr 2002 12:55:33 -0500 (EST) Message-ID: <3CADE514.7020908@cygnus.com> Date: Fri, 05 Apr 2002 09:55:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.9) Gecko/20020328 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [RFA] Fix watchpoints when stepping over a breakpoint 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00171.txt.bz2 > Also bear in mind that if you have this sequence: > - write to x > - other instruction <--- breakpoint here > You will stop based on the watchpoint, because the watchpoint happens > first. You'll get a trap just before you would have hit the > breakpoint. GDB handles this OK, and does report the watchpoint. It's > only if we expected a trap (single stepping for instance) that this > does not work. The current failure is "single step over something > which triggers the watchpoint, landing on something with a breakpoint". > Without my patch, we detect that we are at an address with a > breakpoint, and don't even try to check our watchpoints. I suspect this is a design problem. Blame DECR_PC? The ``stop'' address gets confused with the PC value and the decr's probably screw it. Andrew