From: Pedro Alves <palves@redhat.com>
To: Christopher Friedt <chrisfriedt@gmail.com>, gdb-patches@sourceware.org
Subject: Re: cortex-m xml register descriptions for m-system
Date: Mon, 14 Dec 2015 18:55:00 -0000 [thread overview]
Message-ID: <566F108D.1000401@redhat.com> (raw)
In-Reply-To: <CAF4BF-RuPwFWfDa2Sp7MzYjF8bo1K3xb=jMThSpK4T7gTe+whQ@mail.gmail.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"/>
> </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.
>
> 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.
>
> Just for comparison, the current binutils-gdb arm-m-profile.xml is
> here (https://goo.gl/hpTye8), and the openocd variant is here
> (http://goo.gl/FFn56X).
>
> 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.
>
>
> C
>
Thanks,
Pedro Alves
next prev parent reply other threads:[~2015-12-14 18:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-14 17:05 Christopher Friedt
2015-12-14 18:55 ` Pedro Alves [this message]
2015-12-14 23:11 ` Christopher Friedt
2015-12-15 0:13 ` Pedro Alves
2015-12-15 15:35 ` Christopher Friedt
2015-12-16 13:51 ` Tristan Gingold
2015-12-16 17:13 ` Christopher Friedt
2015-12-17 8:32 ` Tristan Gingold
2018-08-14 18:14 ` Christopher Friedt
2015-12-15 11:44 ` Tristan Gingold
2015-12-15 11:59 ` Pedro Alves
2015-12-15 12:11 ` Pedro Alves
2015-12-15 12:13 ` Pedro Alves
2015-12-15 8:55 ` Yao Qi
2015-12-15 10:25 ` Pedro Alves
2015-12-15 10:32 ` Pedro Alves
2015-12-16 9:49 ` Yao Qi
2015-12-15 9:13 ` Yao Qi
2015-12-15 12:20 ` Christopher Friedt
2015-12-15 15:09 ` Christopher Friedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=566F108D.1000401@redhat.com \
--to=palves@redhat.com \
--cc=chrisfriedt@gmail.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox