From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4585 invoked by alias); 30 Sep 2014 14:11:05 -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 4571 invoked by uid 89); 30 Sep 2014 14:11:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 30 Sep 2014 14:11:02 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8UEAl25032764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 30 Sep 2014 10:10:47 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8UEAiIV023359; Tue, 30 Sep 2014 10:10:44 -0400 Message-ID: <542AB9E3.5090100@redhat.com> Date: Tue, 30 Sep 2014 14:11:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Joel Brobecker 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 References: <5429D9FC.6000509@redhat.com> <542A72F9.5090203@redhat.com> <542A872B.9050203@redhat.com> <542AA806.10804@redhat.com> <20140930135031.GD6927@adacore.com> In-Reply-To: <20140930135031.GD6927@adacore.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-09/txt/msg00895.txt.bz2 On 09/30/2014 02:50 PM, Joel Brobecker wrote: >> 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. I assume that WFAR/DSCR are privileged registers though. On Linux, for example, they're not exported to userspace. > 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... I think it'd be better leave those details to the remote stub / OS though. E.g., this way, qemu's gdbserver stub may support watchpoint variants that the hardware qemu is emulating doesn't support. For instance, as a natural extension of this, we could make it possible for qemu to have non-continuable watchpoints (trap before the instruction that changes memory executes) on all targets, even x86. Or have it trap after the instruction that changes memory, but tell GDB the address of the instruction that triggered the watchpoint (there's no magic number to subtract on x86, due to variable-length instructions). Thanks, Pedro Alves