From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23529 invoked by alias); 30 Sep 2014 10:01:16 -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 23519 invoked by uid 89); 30 Sep 2014 10:01:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-lb0-f179.google.com Received: from mail-lb0-f179.google.com (HELO mail-lb0-f179.google.com) (209.85.217.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 30 Sep 2014 10:01:14 +0000 Received: by mail-lb0-f179.google.com with SMTP id l4so278650lbv.38 for ; Tue, 30 Sep 2014 03:01:10 -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=c7/DNbH1HFXGK7q2QCeZzGRpqtuXmVvNWb55syHzInY=; b=PpgXoYeWzb1QF+UyS/SEY1VslREamRtGYnQpF3hYkwYzfvgJLcMPTV4A3FEt2acNIp pEa49cpR8d94zHeLsgnCd9trRX7MOINXUvbyA/LtetExjT0wSnd3PyKGNzjzdCn8nzJQ eZXj54XT5Rt8wmAlfA+qI6LY2fEY2wjqAVnMLdSbZKfLwjDMOQ+23ao6XPz3svDgju80 T07zR4y18I4li/jURwIXwfIM7SBxA/b/En5Xn5XJOWwuPNYF5VbnjrjvZblaIJMLhdXa 8wBUCKxGYdpNiu51wjVW5CGwFYxcUbsV1LQXSIKMh048Ab0xION3EdJzglBf3zQHLKmy 6aVA== X-Gm-Message-State: ALoCoQmrCvJNIdtWedgqSPE8gwtl7A0ASpW2YYUarRsdA8RDYx4CRKWFbZ60h2M+7N3j8xHVDaT2 X-Received: by 10.112.134.101 with SMTP id pj5mr43081119lbb.47.1412071269051; Tue, 30 Sep 2014 03:01:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.130.161 with HTTP; Tue, 30 Sep 2014 03:00:49 -0700 (PDT) In-Reply-To: <542A72F9.5090203@redhat.com> References: <5429D9FC.6000509@redhat.com> <542A72F9.5090203@redhat.com> From: Peter Maydell Date: Tue, 30 Sep 2014 10:01: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/msg00878.txt.bz2 On 30 September 2014 10:08, Pedro Alves wrote: > On 09/29/2014 11:53 PM, Peter Maydell wrote: >> 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? In general it's unwise to assume that statements about the ARM A and R profiles carry across to M profile... v7M profile watchpoints are rather different from v7AR watchpoints in terms of how you set them, how they're reported, etc, and they're always asynchronous (other insns may execute after the one which triggers the wp before the debug event fires). > 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. My QEMU patch is for the built in gdbstub, which is completely different code to the emulation of the CPU's own architected debug hardware. (We implement the latter only for v7 and above, not v6.) It doesn't seem very sensible to me to deliberately provide unhelpful asynchronous watchpoint support on v6-and-lower guest CPUs just because that's what the hardware does, especially since it would mean we wouldn't interoperate with current gdb. (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.) > Now I'm confused on the mention of the Linux kernel > subtracting 8 from the PC to help GDB. I can't find that > anywhere in the kernel's sources. This is a reference to the standard ARM exception entry behaviour where the value saved to the link register may be +2, +4 or +8 from the "preferred return address" for the exception. The kernel handles this via a 'vector_stub' macro that adjusts the value read from LR so the rest of the kernel can deal simply in preferred return addresses. Since sync. watchpoints are a kind of data abort they go through here, with a correction value of 8: http://lxr.free-electrons.com/source/arch/arm/kernel/entry-armv.S#L1043 thanks -- PMM