From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71345 invoked by alias); 14 Dec 2015 23:11:47 -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 71330 invoked by uid 89); 14 Dec 2015 23:11:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 X-HELO: mail-ob0-f177.google.com Received: from mail-ob0-f177.google.com (HELO mail-ob0-f177.google.com) (209.85.214.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 14 Dec 2015 23:11:45 +0000 Received: by obcno2 with SMTP id no2so25424283obc.3 for ; Mon, 14 Dec 2015 15:11:43 -0800 (PST) X-Received: by 10.60.63.34 with SMTP id d2mr27999770oes.75.1450134703441; Mon, 14 Dec 2015 15:11:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.69.69 with HTTP; Mon, 14 Dec 2015 15:11:24 -0800 (PST) In-Reply-To: <566F108D.1000401@redhat.com> References: <566F108D.1000401@redhat.com> From: Christopher Friedt Date: Mon, 14 Dec 2015 23:11:00 -0000 Message-ID: Subject: Re: cortex-m xml register descriptions for m-system To: Pedro Alves Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg00272.txt.bz2 On Dec 14, 2015 1:55 PM, "Pedro Alves" wrote: > > On 12/14/2015 05:04 PM, Christopher Friedt wrote: > > Hi list, > > > > I've been using GDB and OpenOCD to debug ARM Cortex-M devices for > > quite a while. One thing that I always noticed when using OpenOCD is > > that the m-system registers are listed, which is *incredibly* useful > > for writing code on just about any Cortex-M microcontroller. > > > > Somewhat recently, Qemu has also begun to support Cortex-M based > > virtual devices, and it seems to be fairly usable. > > > > The down side, is that they do not expose the m-system registers, > > simply because binutils-gdb does not (at this time) have an XML file > > for them. > > > > Just to catch anyone up to speed who might be reading this, the > > m-system registers are > > > > MSP (main stack pointer) > > PSP (process stack pointer) > > PRIMASK (1-bit register that says if interrupts are enabled) > > BASEPRI (8-bit register that sets the NVIC base priority) > > FAULTMASK (1-bit register that says if fault interrupts are enabled) > > CONTROL (3-bit register that indicates presence of FP, whether PSP is > > selected, and whether running in unprivileged mode) > > > > Now, these are "system" registers, and on a full blown microprocessor, > > it might be unusual to expose them, but on a microcontroller, it's > > quite important. The other debuggers that I have seen (IAR, > > specifically) also list the m-system registers along with the general > > purpose ones for Cortex-M. > > > > The following XML is sufficient to describe the m-system registers so > > that they appear to the GDB client. > > > > > > > > > > > > > > > > > > > > Does GDB need to be aware of these registers at all? That is, does gdb > need to be aware of org.gnu.gdb.arm.m-system? Usually GDB needs to > be aware of specific registers if for instance Dwarf can refer to them. > Otherwise, the design of xml descriptions is such that you're free > to send any additional registers you want without a specific feature. > GDB will show them. Hmm... It's hard for me to say. The MSP and PSP are banked stack pointers, control instructs the core which stack pointer to use, and they are also tightly coupled to exception entry, so I would lean towards yes? > > The first question I would ask for clarification from the binutils-gdb > > developers, is, which regnum is appropriate to assign to each of those > > m-system registers? Should these registers enumerate starting with 26 > > (resuming from the xpsr)? > > I don't think the regnums matter. GDB should be adjusting itself > dynamically. > > The regnums only matter for backward compatibility with stubs that > don't report XML descriptions. In that case, GDB will fallback to > internal XML descriptions guessed from e.g., the binary loaded, and > in that case the expected offsets in the g/G packets must match what > the stub actually sends. Exactly, I just want to ensure that the numbering *is* backward compatible with stubs that don't support XML descriptions. I believe anything beyond 26 should be fine, as it does not interfere with core registers, the PSR, or FPA registers. Is that a correct assumption? > Even though all Cortex-M CPUs have these registers, userspace > debuggers/servers can't access them, right? With the chips I have worked with, I definitely could access (i.e. write to) the msp, psp, primask, faultmask, basepri, and control registers, via OpenOCD. I think the only non-addressible register that can't be written is the xpsr, iirc (which is not part of m-system).