From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20926 invoked by alias); 1 Sep 2014 08:57:49 -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 20903 invoked by uid 89); 1 Sep 2014 08:57:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 01 Sep 2014 08:57:45 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id F19F21163F5; Mon, 1 Sep 2014 04:57:42 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fQ5kcp3U9Bxg; Mon, 1 Sep 2014 04:57:42 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id C15561163F3; Mon, 1 Sep 2014 04:57:42 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 7EA6147590; Mon, 1 Sep 2014 10:57:43 +0200 (CEST) Date: Mon, 01 Sep 2014 08:57:00 -0000 From: Joel Brobecker To: gdb@sourceware.org Cc: Fabien Chouteau Subject: question about ARM watchpoints Message-ID: <20140901085743.GG4981@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-09/txt/msg00000.txt.bz2 Hello, Some of our ARM bareboard testing is done over QEMU, and we came across an issue with watchpoints. The testcase is very simple: We set a watchpoint on a integer global variable, and then resume the execution until the variable gets updated. Everything works pretty well, except that we noticed that GDB stops 2 instructions after the variable update, rather than at the next instruction. For instance, this is the code we have: 0x00000060: movt r3, #0 0x00000064: str r2, [r3] <<<--- new value stored here 0x00000068: pop {r11, pc} Looking at the infrun+remote debug traces, we can see that QEMU sends GDB a watchpoint event with the PC set to the insn after the store: infrun: stop_pc = 0x68 infrun: stopped by watchpoint infrun: stopped data address = 0xd820 At this point, GDB then does a single-step, which takes us past the "pop" to the next instruction. My guess is that GDB probably thinks that we got notified before the watched data got modified, and thus needs to do a single-step in order to read the new value. The question then becomes: Is QEMU behaving correctly, in which case we should be modifying GDB, or is QEMU signaling GDB too late, in which case we should be fixing QEMU? We tried finding an answer to that question, but without much success. We found the following in the ARMv7-M Architecture Reference Manual, for instance: For all other debug events, including PC match watchpoints, the address is that of an instruction which in a simple execution model is one which executes after the instruction which caused the event, but which itself has not executed But I'm a little confused when reading this, and I am not even sure that it applies to data watchpoints. We tried experimenting with other systems that do not involve QEMU, but came up short. Surprisingly, watchpoints didn't even trigger when trying on a system that runs GNU/Linux, for instance. Slightly better, but still not completely convincing - we tried debugging via stlink, a tool which provides a gdbserver-like interface. The watchpoint was inserted, and triggered an event, but stlink reported a SIGTRAP instead of a watchpoint event. The only element which might be a clue is the fact that the PC at the SIGTRAP event is at the instruction after the store, so it might be confirming QEMU's behavior and indicate that GDB should be modified. I am sending this email to ask if anyone might have a more authoritative answer than ours. If we were able to know for sure, we can then work on fixing the bug on the right side of the fence :). Thanks! -- Joel