From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15601 invoked by alias); 29 Sep 2014 18:23: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 15586 invoked by uid 89); 29 Sep 2014 18:23:30 -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-f45.google.com Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com) (209.85.215.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 29 Sep 2014 18:23:29 +0000 Received: by mail-la0-f45.google.com with SMTP id q1so7008447lam.32 for ; Mon, 29 Sep 2014 11:23:25 -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:from:date:message-id:subject:to:cc :content-type; bh=Jt/YOo14245qJOa822WfkNmLVJPjxsXoKpw9DbhbiJQ=; b=fCEgv9g/OfJy5rrTNxrDNfyImInjNrFSPr6ExA4lU82sldmwBllzOjO2Nffh+ceb23 6voLA1Unrt80sLpR3qfBWh/j1Icexyycdv3xMdF8ODoL03xAEoLsgZTbqMUtro9SkX0v NNiMRucjX6MU+jsw2Vkb+5g5zXNcxBTgpbCdhsMYtlh0rAI1PveG4uuLX0qlLyBraY+P M2SyQnK7gEN/QMT28Jz7gsqzaMDs5LAtisbnBgdHRM1y+1nSVIUe3OGoTtABEyRud5JQ VzXNCDTPNXMfaCJMMRg7Mkq0GcuqcL7PirybS0eNuPdV+mxfFWIpNocGP9fX/CKtyHzK xqbg== X-Gm-Message-State: ALoCoQnkKf5khkSg1dCkY4+HAeFxIgV/tpIfNX87xE7xgQgvveoM69RyFavd/VWwydYBrpNRpqY0 X-Received: by 10.112.35.199 with SMTP id k7mr1144234lbj.76.1412015005731; Mon, 29 Sep 2014 11:23:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.130.161 with HTTP; Mon, 29 Sep 2014 11:23:05 -0700 (PDT) From: Peter Maydell Date: Mon, 29 Sep 2014 18:23:00 -0000 Message-ID: Subject: Re: [RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint To: Joel Brobecker Cc: Marcus Shawcroft , Terry.Guo@arm.com, Marcus Shawcroft , "lgustavo@codesourcery.com" , yao@codesourcery.com, gdb-patches@sourceware.org, Will Deacon , "gareth@blacksphere.co.nz >> Gareth, McMullin" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2014-09/txt/msg00846.txt.bz2 Joel Brobecker wrote: > I have been trying to understand the various contributions, and > I admit I am still not quite sure... > > Does it look like the patch I proposed is correct? It seems to be > supported by Terry Guo's experiments as well... Note that the ARMv7 architecture allows watchpoints to be implemented as *asynchronous*, in which case what you will see is that you take a watchpoint exception but it may not fire until after the instruction that triggers the watchpoint and possibly several following instructions have all finished execution. This may be what you are seeing in your hardware tests. For *synchronous* watchpoints, the behaviour is that the CPU stops *before* execution of the instruction which triggers the fault, and the memory access does not take place. This is pretty clearly described in the ARM ARM (see DDI0406C.c section C3.4.4 "Synchronous and asynchronous Watchpoint debug events" and the referenced "Effects of data-aborted instructions" section). For ARMv8 (so including all AArch64 CPUs) watchpoints must be synchronous. 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). GDB should continue to set have_nonsteppable_watchpoint for ARM architectures, indicating: * watchpoints fire before the insn executes * you need to disable the watchpoint to successfully singlestep the insn as this is correct for synchronous watchpoints. If you have h/w with asynchronous watchpoints then there really isn't much you can do about stopping in the right place. Ideally I guess gdb would not do a step in that case, but I don't think it has access to enough info about the target CPU to know this (the kernel does get this info in the DBGDSCR.MOE register field, which is different for synchronous and asynchronous watchpoint events). thanks -- PMM