From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9678 invoked by alias); 30 Sep 2014 14:50:39 -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 9621 invoked by uid 89); 30 Sep 2014 14:50:39 -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-f172.google.com Received: from mail-lb0-f172.google.com (HELO mail-lb0-f172.google.com) (209.85.217.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 30 Sep 2014 14:50:38 +0000 Received: by mail-lb0-f172.google.com with SMTP id b6so4729774lbj.17 for ; Tue, 30 Sep 2014 07:50:34 -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=YSSBqs+d5kWSOm3PWpc31zI2QCfvBra853hkpAztcWM=; b=cM7t8pmYwmGLSdD1dNQ/Y4nLuu/elRQL0bay+opWMgvZ925j7I9nJi5SXbeVJkP65u QsRp60Zg+nKcJ5+RgQwJ6Vx/9dW2e4/koz/OYZwR7WL83loZAgIQ0mDTRK8uVF/Sgs5l +VCC/n3WA7lHL+bUIAotRkOxSuVd6mDp3jBh831foIOlwjgfzIKw/fFIwjvkXUa2/O+y GXJ+qJ+/kay7ZsSIs8GTMKlWI7riEawuU+xnCy/VaVW9rPlG2ilmyRvfBKWBg+J+aECP feUZH6N+Gg8ao4PyzJ+3ZBw9t4NHDQuGhk2hRHMi25RQJqAN6ZG1kawQDfOQ+EzpbEmo KYkA== X-Gm-Message-State: ALoCoQkotQD+p+snvZsl1ZbqsBhFuf2OUFKTOKYNnBtUzDzkiS8+arG7mZSFyPnHoHlh7PzVSyki X-Received: by 10.152.2.41 with SMTP id 9mr47815826lar.79.1412088633293; Tue, 30 Sep 2014 07:50:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.130.161 with HTTP; Tue, 30 Sep 2014 07:50:12 -0700 (PDT) In-Reply-To: <20140930142612.GE6927@adacore.com> References: <5429D9FC.6000509@redhat.com> <542A72F9.5090203@redhat.com> <542A872B.9050203@redhat.com> <542AA806.10804@redhat.com> <20140930135031.GD6927@adacore.com> <542AB9E3.5090100@redhat.com> <20140930142612.GE6927@adacore.com> From: Peter Maydell Date: Tue, 30 Sep 2014 14:50:00 -0000 Message-ID: Subject: Re: [RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint To: Joel Brobecker Cc: Pedro Alves , 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/msg00901.txt.bz2 On 30 September 2014 15:26, Joel Brobecker wrote: > That's very interesting. When I talked to one of our QEMU developers > in house about this, he wasn't even sure if it was possible for > QEMU to stop at the instruction triggering the watchpoint. Now, > we know it is, but it could be simpler for QEMU to implement the > same policy on all targets. QEMU's stub has to implement "act like the hardware does" for each individual target CPU, because that's what existing gdb implementations in the field expect. "Act the same in the stub regardless of target CPU" is what we used to do and the result was not stopping in the right place. The actual in-QEMU implementation is pretty trivial, since we already need to support both behaviours in order to correctly emulate the architectural debug support we expose to guest OSes, and it's then just a matter of setting or not setting a flag when we set up the wp. -- PMM