From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14663 invoked by alias); 19 Sep 2014 17:31:32 -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 14654 invoked by uid 89); 19 Sep 2014 17:31:32 -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; Fri, 19 Sep 2014 17:31:31 +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 s8JHVHDX001590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 19 Sep 2014 13:31:17 -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 s8JHVCAK021204; Fri, 19 Sep 2014 13:31:14 -0400 Message-ID: <541C6860.9070907@redhat.com> Date: Fri, 19 Sep 2014 17:31:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Marcus Shawcroft CC: Terry Guo , Marcus Shawcroft , lgustavo@codesourcery.com, Joel Brobecker , Yao Qi , "gdb-patches@sourceware.org" , Will Deacon , peter.maydell@arm.com, "gareth@blacksphere.co.nz >> Gareth McMullin" Subject: Re: [RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint. References: <1410786062-19274-1-git-send-email-brobecker@adacore.com> <87bnqf2578.fsf@codesourcery.com> <20140916115936.GM4871@adacore.com> <5418279A.1040604@codesourcery.com> <20140916124814.GO4871@adacore.com> <54183681.3010504@codesourcery.com> <5418556E.7010502@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-09/txt/msg00637.txt.bz2 Hi Marcus, On 09/18/2014 12:40 PM, Marcus Shawcroft wrote: > On 16 September 2014 16:21, Pedro Alves wrote: >> Hi Terry, Marcus, >> >> Can someone at ARM shed some light on this, please? >> >> This thread is here: >> >> https://sourceware.org/ml/gdb-patches/2014-09/msg00498.html >> >> And the discussion started in another thread here: >> >> https://sourceware.org/ml/gdb/2014-09/msg00000.html >> >> I've just added a test that hopefully helps with this, btw: >> >> https://sourceware.org/ml/gdb-patches/2014-09/msg00535.html >> >> I'm also wondering whether Aarch64 needs adjustment as well. >> > In aarch32 execution state a watch point event is taken as a data > abort with the PC containing the address of the faulting instruction + > 8 irrespective of thumb mode. So the documentation is actually wrong for thumb? Or you're saying that for Thumb2, while it'd be 4 for Thumb 1? If you're talking about something else, not DBGWFAR (what I think Luis pointed out before), then can you give a pointer to where these other watch point events are documented? > > The linux kernel adjusts the reported PC by subtracting 8 such that > the ptrace interface will indicate the address of the faulting > instruction. Hmm. So when the data abort triggers at fault+8, the instruction that triggered the abort hasn't actually completed, right? No memory has changed yet. So if nothing does the adjustment, like Gareth found out happens with the Black Magic Probe, then we'll resume execution from the wrong address/instruction (with the effects of the skipped instructions missing, including the memory write...). Did I understand that right? (Gareth, is that what you see?) > Peter Maydell's proposed qemu patch referenced in the thread above > appears to me to align the gdbstub behaviour in qemu with the linux > kernel ptrace() interface behaviour. > > w.r.t DBGWFAR, it's use is described as deprecated in ARM ARMv7-A&R > Issue C.c c11.11.45. It is not used by linux kernel. Thanks, Pedro Alves