From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20921 invoked by alias); 5 Sep 2014 08:17:46 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 20879 invoked by uid 89); 5 Sep 2014 08:17:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 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; Fri, 05 Sep 2014 08:17:44 +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 s858Hdar006009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 5 Sep 2014 04:17:40 -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 s858Hbar023769; Fri, 5 Sep 2014 04:17:38 -0400 Message-ID: <540971A1.2040506@redhat.com> Date: Fri, 05 Sep 2014 08:17:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Joel Brobecker CC: Gareth McMullin , gdb@sourceware.org Subject: Re: question about ARM watchpoints References: <20140901085743.GG4981@adacore.com> <540903B0.3000009@redhat.com> <20140905035127.GA27655@adacore.com> In-Reply-To: <20140905035127.GA27655@adacore.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-09/txt/msg00016.txt.bz2 On 09/05/2014 04:51 AM, Joel Brobecker wrote: >> So sounds like this line should be skipped on ARMv7-M: >> >> arm-tdep.c: set_gdbarch_have_nonsteppable_watchpoint (gdbarch, 1); >> >> Could you try removing it? >> >> But then I wonder why we never heard of this before. Are there >> ARMv7-M's that behave differently? And what about ARMv6-M ? > > That's what I wanted to try too, and will do soon. As to why we never > heard of this before - the only affirmative answer would be from someone > better able to undertand the docs than me. But here's a wild guess: the > fact that GDB stopped one instruction too late is invisible to the user > 99% of the time. What triggered me seeing it was a change in code > generation which caused the update to be at the penultimate instruction > of a function. I wouldn't have seen it if the update was anywhere before > that. Ah, indeed. Hmm. Sounds like we need a test to catch this. :-) Most preferably, a portable one, which may be tricky. I've written something like this before: volatile int i1; volatile int i2; volatile int i3; int main () { i1 = 1; i2 = 2; i3 = 3; } assuming each write would be one insn, but, then that turned out to be a wrong assumption, for ARM even, I think. Hmm... I had an idea. How about: volatile int global; set_global (int val) { global = val; } main () { set_global (1); set_global (2); } #01 - run to main #02 - set a _software_ watchpoint on i1 (w/ hw watchpoints force-disabled) #03 - continue #04 - (GDB single-steps the inferior, and checks the watchpoint's value at each step.) #05 - watchpoint triggers #06 - the PC now points to the instruction right after the instruction that actually caused the memory write. So this is the address a hardware watchpoint should present the stop to the user too. Store the PC address. #07 - delete the software watchpoint #08 - set a _hardware_ watchpoint on i1. #09 - continue #10 - hardware watchpoint triggers. PC should point to the address stored in #6. Thanks, Pedro Alves