This is the mail archive of the
mailing list for the GDB project.
Re: cortex-m xml register descriptions for m-system
- From: Christopher Friedt <chrisfriedt at gmail dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 14 Dec 2015 18:11:24 -0500
- Subject: Re: cortex-m xml register descriptions for m-system
- Authentication-results: sourceware.org; auth=none
- References: <CAF4BF-RuPwFWfDa2Sp7MzYjF8bo1K3xb=jMThSpK4T7gTe+whQ at mail dot gmail dot com> <566F108D dot 1000401 at redhat dot com>
On Dec 14, 2015 1:55 PM, "Pedro Alves" <firstname.lastname@example.org> 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.
> > <feature name="org.gnu.gdb.arm.m-system">
> > <reg name="msp" bitsize="32" type="data_ptr"/>
> > <reg name="psp" bitsize="32" type="data_ptr"/>
> > <reg name="primask" bitsize="1" type="int8"/>
> > <reg name="basepri" bitsize="8" type="int8"/>
> > <reg name="faultmask" bitsize="1" type="int8"/>
> > <reg name="control" bitsize="3" type="int8"/>
> > </feature>
> 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
> > 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
> 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).