From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5782 invoked by alias); 29 Sep 2014 22:54:17 -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 5771 invoked by uid 89); 29 Sep 2014 22:54:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-la0-f49.google.com Received: from mail-la0-f49.google.com (HELO mail-la0-f49.google.com) (209.85.215.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 29 Sep 2014 22:54:15 +0000 Received: by mail-la0-f49.google.com with SMTP id ge10so4445598lab.36 for ; Mon, 29 Sep 2014 15:54:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PPsIQ+e+fyFkU2ZDmhfE9j9bT+Gt5ElwqMVOtQgytq8=; b=H3fvtMlPYGzXVFv0TjzjKimObZpKh8LzTcsA828c9e1+YxzKu374jRdmGwQMzyPyok 7FMCozBNVMpIb1gY/OAJoss2By+nxyka0KyoYdaWk0q5ZvR/e/lWFdrfyDm2Qgf2Xup/ 2l7qK/broogv/8xORXBxAAGjRHsoMb9B81e65i4LXIBtIcwGkDmWPhNdk2G5JSi7uLld mmha3Xt0mag127QiqAq4MIdpaZYlZ7RnAH+JBB/j4LiYkOedFrU+9OLx609Q05nH/Fms gfM8j5+aueqWFjkIhIouwirZgk3p3Px7q1ZH++9woVkhPcfiMjR7tAcpAPg81zK2ctsD 1ufw== X-Gm-Message-State: ALoCoQm2yO5MFW01z0yQkUITT2iDMDtYgCsTwdzO+uLO7NzWOqVvBbl2X3f3X+LnO/qg+SVcRH9K X-Received: by 10.112.35.199 with SMTP id k7mr2332928lbj.76.1412031251968; Mon, 29 Sep 2014 15:54:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.130.161 with HTTP; Mon, 29 Sep 2014 15:53:51 -0700 (PDT) In-Reply-To: <5429D9FC.6000509@redhat.com> References: <5429D9FC.6000509@redhat.com> From: Peter Maydell Date: Mon, 29 Sep 2014 22:54:00 -0000 Message-ID: Subject: Re: [RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint To: Pedro Alves 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" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2014-09/txt/msg00860.txt.bz2 On 29 September 2014 23:15, Pedro Alves wrote: > On 09/29/2014 07:23 PM, Peter Maydell wrote: >> Note that the ARMv7 architecture allows watchpoints to >> be implemented as *asynchronous* > I only have DDI 0406C.b handy, which says: > > ARMv7 permits watchpoints to be either synchronous or asynchronous. An implementation can implement > synchronous watchpoints, asynchronous watchpoints, or both. It is IMPLEMENTATION DEFINED under what > circumstances a watchpoint is synchronous or asynchronous. > > Ouch. So this IMPLEMENTATION DEFINED note means this isn't really > in control of the software/debugger, i.e., nothing a stub/probe > could tweak, but instead baked into the specific ARM chip? Correct. IMPDEF means that it is the choice of the CPU implementation which behaviour to take. >> QEMU's built in gdbstub was incorrectly not implementing >> synchronous watchpoints (ie it was halting after the >> execution of the offending insn, not before). This is fixed >> by the QEMU patch referenced earlier, and with that patch >> QEMU and GDB interoperate correctly (on ARM and also on >> other architectures which have the "stop before insn" >> watchpoint semantics). > > "Incorrect" may be too strong then, but understood. I wrote the QEMU patch; I'm happy to call our old behaviour incorrect :-) > So even on Linux, iiuc, it's possible to see a watchpoint > trigger after the write has already happened; it'll depend on > hardware implementation. Yes. > 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. > The next option would be something in the xml target description. > It's be a global per-target, so no mixing types of watchpoints. > (That is either sent to gdb by the stub, or loaded manually > with "set tdesc filename".) > > Failing all that, we may want a "set arm ..." knob to > override the default... > > 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? If this is a v6-and-earlier thing I'd certainly be tempted to sweep the issue under the carpet... thanks -- PMM