This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] (ARM Cortex-M) FPU and PSP aware exception frame unwinder
- From: Pedro Alves <palves at redhat dot com>
- To: James-Adam Renquinha Henri <arenquinha at cimeq dot qc dot ca>, Tristan Gingold <gingold at adacore dot com>
- Cc: gdb-patches at sourceware dot org, Christopher Friedt <chrisfriedt at gmail dot com>
- Date: Fri, 22 Apr 2016 15:16:55 +0100
- Subject: Re: [PATCH] (ARM Cortex-M) FPU and PSP aware exception frame unwinder
- Authentication-results: sourceware.org; auth=none
- References: <5706DA27 dot 1070308 at cimeq dot qc dot ca> <570C1D85 dot 1060706 at redhat dot com> <C52395DC-8725-47F6-96DE-4DA0A9FDFD4F at adacore dot com> <57180D4F dot 1030001 at cimeq dot qc dot ca>
On 04/21/2016 12:14 AM, James-Adam Renquinha Henri wrote:
> When using Qemu, gdb uses the
> "org.gnu.gdb.arm.m-profile" feature from binutils-gdb and the system
> registers are lacking from the XML file. This is the problem Christopher
> Friedt had in the thread;
> - If the system registers were in "org.gnu.gdb.arm.m-profile", then we
> could rely on their presence and put them in the `gdb_regnum` enum in
> arch/arm.h and assign them fixed offsets, removing the need to get them
> by name;
> - By finding registers by name, we're dependent of the supplied target
> description and even getting PSP (which is always available on any
> Cortex-M core BTW) can fail, and the code I provided will crash.
In general, looking up by name can return an unrelated register
that some stub decided to include as extra register in its target
description, that may not be the register GDB is looking for.
So registers that are necessary for correct operation should be
included in some standard target feature, so that GDB knows for
sure what it's getting.
> (I realized LR is accessible via `ARM_LR_REGNUM`. Ooops)
> I'm not sure to follow, but it seems the inclusion of the system
> registers into "org.gnu.gdb.arm.m-profile" is still an open question. My
> opinion is to include them, because all Cortex-M have them.
It may work to make them optional registers in the feature,
so that older targets that don't report them continue working.
Dunno, a new target feature for system registers may be better.
This can be
> seen in B1.4 of the ARMv6-M Reference Manual:
> The ARMv6-M profile has the following registers closely coupled to
> the processor:
> - General purpose registers R0-R12.
> - Two Stack Pointer registers, SP_main and SP_process. These are
> banked versions of SP, also described as R13.
> - The Link Register, LR also described as R14.
> - The Program Counter, PC, sometimes described as R15.
> - Status registers for flags, execution state bits, and the current
> exception number.
> - A mask register, PRIMASK, used to manage the prioritization scheme
> for exceptions and interrupts.
> - A control register, CONTROL that identifies the current stack.
> (later, they define SP_main as synonymous to MSP, and likewise for
> SP_process with PSP)
> Cortex-M0 and Cortex-M0+ are based on the ARMv6-M profile, and that
> profile is upward compatible with the ARMv7-M profile which is used in
> the Cortex-M3 and Cortex-M4(F): code compiled for Cortex-M0 can run on
> any Cortex-M. Meaning, ARMv6-M is the lowest common denominator of all
> Cortex-M. If the ARMv6-M architecture has these system registers, then
> all Cortex-M have them.
The question is whether on a system with some sort of
userspace / kernel separation, such registers would be exposed to
userspace. E.g., on x86 Linux, ptrace does not expose privileged
registers, so the core x86 target feature does not include any.
See bottom half of:
(The suggestion in the top halve was assuming gdb didn't have
to know anything about these registers, which turned out to