From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13683 invoked by alias); 30 Sep 2014 12:54:51 -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 13660 invoked by uid 89); 30 Sep 2014 12:54:48 -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 12:54:47 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8UCsYct028935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 30 Sep 2014 08:54:35 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8UCsUUS012389; Tue, 30 Sep 2014 08:54:31 -0400 Message-ID: <542AA806.10804@redhat.com> Date: Tue, 30 Sep 2014 12:54: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: Peter Maydell CC: Joel Brobecker , 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> In-Reply-To: <542A872B.9050203@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-09/txt/msg00886.txt.bz2 On 09/30/2014 11:34 AM, Pedro Alves wrote: >> (Similarly, >> we provide watchpoint support in our stub even if >> the CPU we're emulating has no watchpoint support >> of its own at all. Think of us as like a JTAG probe.) > > Well, it seems to me that GDB, on v6-and-lower is > doing the wrong thing for real halt-mode/jtag probes. > If we fix that in GDB, then your qemu patch breaks > things on v6. 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. Thanks, Pedro Alves