From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15846 invoked by alias); 30 Sep 2014 09:08:33 -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 15836 invoked by uid 89); 30 Sep 2014 09:08:30 -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 09:08:29 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8U98DqW007280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 30 Sep 2014 05:08:13 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8U989w9021456; Tue, 30 Sep 2014 05:08:10 -0400 Message-ID: <542A72F9.5090203@redhat.com> Date: Tue, 30 Sep 2014 09:08: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> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-09/txt/msg00874.txt.bz2 On 09/29/2014 11:53 PM, Peter Maydell wrote: > On 29 September 2014 23:15, Pedro Alves wrote: >> On 09/29/2014 07:23 PM, Peter Maydell wrote: >> "Incorrect" may be too strong then, but understood. > > I wrote the QEMU patch; I'm happy to call our old > behaviour incorrect :-) :-) >> I think the most flexible would be if the watchpoint >> event reported to GDB indicated which type it got, so >> that'd support the case an arch ever supports mixing both >> kinds of watchpoints. > > Ha, I hadn't noticed that the architecture permits an > implementation to provide both kinds (or indeed to > have one watchpoint that might fire in either way), but > you're right that it's theoretically allowed. Yeah. But not just ARM -- but more flexible for all archs and emulators. >> Or we just forget all this, assuming that ARM chips that >> have async watchpoints will disappear into obsolescence >> forever soon enough. :-) > > There's an assertion in this LKML post from 2010: > https://lkml.org/lkml/2010/4/14/127 > that v7 cores do actually all generate synchronous > watchpoint exceptions (even though architecturally > they're permitted not to). Was your test h/w a v6? Joel's test was against qemu (without your patch). Terry's tests were against armv7l and armv8. Both synchronous. The report that confuses me is Gareth's: https://sourceware.org/ml/gdb/2014-09/msg00013.html As it sounds like he has v7-m hardware that has asynchronous behavior. Gareth, can you confirm this, please? Still, in any case, from that LKML post: "v6 cores are the opposite; they only generate asynchronous watchpoint exceptions". So, eh!? Does your qemu patch take this into account? Seems like it should. In Linux's sources I see this: /* Determine number of usable WRPs available. */ static int get_num_wrps(void) { /* * On debug architectures prior to 7.1, when a watchpoint fires, the * only way to work out which watchpoint it was is by disassembling * the faulting instruction and working out the address of the memory * access. * * Furthermore, we can only do this if the watchpoint was precise * since imprecise watchpoints prevent us from calculating register * based addresses. * * Providing we have more than 1 breakpoint register, we only report * a single watchpoint register for the time being. This way, we always * know which watchpoint fired. In the future we can either add a * disassembler and address generation emulator, or we can insert a * check to see if the DFAR is set on watchpoint exception entry * [the ARM ARM states that the DFAR is UNKNOWN, but experience shows * that it is set on some implementations]. */ if (get_debug_arch() < ARM_DEBUG_ARCH_V7_1) return 1; So, even on Linux, on v6, etc. (< v7.1), it seems to me that we're indeed very likely to get _asynchronous_ watchpoints reported to GDB, and so this in GDB: /* Watchpoints are not steppable. */ set_gdbarch_have_nonsteppable_watchpoint (gdbarch, 1); should be skipped on < v7.1 ... > If this is a v6-and-earlier thing I'd certainly be tempted > to sweep the issue under the carpet... Thanks, Pedro Alves