This is the mail archive of the
mailing list for the GDB project.
Re: cortex-m xml register descriptions for m-system
- From: Pedro Alves <palves at redhat dot com>
- To: Christopher Friedt <chrisfriedt at gmail dot com>, gdb-patches at sourceware dot org
- Date: Mon, 14 Dec 2015 18:55:09 +0000
- 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>
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"/>
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.
> 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.
> Just for comparison, the current binutils-gdb arm-m-profile.xml is
> here (https://goo.gl/hpTye8), and the openocd variant is here
> The second question I would like to ask is, what is the best way to
> add this XML? Should it
> 1) Should it be inserted directly into arm-m-profile.xml?
> 2) Should it be included from arm-m-profile.xml as arm-m-system.xml?
> IMHO, the 1st or 2nd option would make sense, as all Cortex-M's
> contain these registers.
Even though all Cortex-M CPUs have these registers, userspace
debuggers/servers can't access them, right?
> I'm asking because I have a patch ready to submit for this on a whim's
> notice, but would just like to get some buy-in ahead of time.