From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19372 invoked by alias); 30 Sep 2014 13:50:41 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 19360 invoked by uid 89); 30 Sep 2014 13:50:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 30 Sep 2014 13:50:34 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 61182116251; Tue, 30 Sep 2014 09:50:32 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PSBpVMQDly5J; Tue, 30 Sep 2014 09:50:32 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id BD93B11611C; Tue, 30 Sep 2014 09:50:31 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id E60A6497DA; Tue, 30 Sep 2014 06:50:31 -0700 (PDT) Date: Tue, 30 Sep 2014 13:50:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: Peter Maydell , Marcus Shawcroft , Terry.Guo@arm.com, Marcus Shawcroft , "lgustavo@codesourcery.com" , yao@codesourcery.com, gdb-patches@sourceware.org, Will Deacon , "Gareth, McMullin" Subject: Re: [RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint Message-ID: <20140930135031.GD6927@adacore.com> References: <5429D9FC.6000509@redhat.com> <542A72F9.5090203@redhat.com> <542A872B.9050203@redhat.com> <542AA806.10804@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <542AA806.10804@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-09/txt/msg00892.txt.bz2 > BTW, given v7-m behaves like this as well, it sounds > like this may not be the last we hear about asynchronous > watchpoints (thinking bare-metal here). > > But, I've given this further thought while cooking lunch. :-) > > Given that with asynchronous watchpoints, any number > of instructions could have been executed, which isn't > exactly the same as always triggering the exception just > after the instruction completes, and, since the instruction > that triggered the watchpoint can be discovered (in WFAR), I > think we should indeed assume synchronous watchpoints by > default, and then handle asynchronous watchpoints by > augmenting the watchpoint event (packet) reported to GDB > by indicating the asyncness and the instruction > that triggered the exception (if known). On such targets, > GDB could be a bit more helpful and if execution stops far > from where the watchpoint triggered, it could tell that to > the user. On Linux, if we wanted to expose this to the > ptracer, we'd stuff it somewhere in the SIGTRAP's siginfo. > > How does that sound? > > In a nutshell, less guesswork for GDB, by making the > target be more precise in its event reporting. I was thinking about something along the same lines; a little less sophisticated perhaps: check WFAR, and if far enough, then cancel the single-step. Informing the user about how far would certainly be a useful info for the user. The only part I'm unclear about is whether it's OK to check WFAR when in synchronous mode, and whether it'll have a WFAR=0 in case of a synchronous breakpoint... -- Joel