Re: cortex-m xml register descriptions for m-system

[Pedro Alves <palves@redhat.com>]

On 12/14/2015 11:11 PM, Christopher Friedt wrote:
> On Dec 14, 2015 1:55 PM, "Pedro Alves" <palves@redhat.com> wrote:
>>
>> 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?

If you can think of some gdb feature that would need hard coding
the awareness of the existence of these registers, then that's an
indication you'd want to create a new standard target feature to wrap
the registers, so gdb could check whether the feature is present
on the target gdb just connected to.  Then gdb's ARM backend code (gdb/arm-tdep.c)
would check whether the feature is listed as present in the target description
the stub sent, and if it is present, validate that the corresponding
set of register registers is included in the reported description,
like is done already for other standard features:

  https://sourceware.org/gdb/onlinedocs/gdb/Standard-Target-Features.html

TBC, the stub is free to send other unknown registers in the target
description.  That is, if you adjust your stub to send a description
like this:

<!DOCTYPE feature SYSTEM "gdb-target.dtd">
<feature name="org.gnu.gdb.arm.m-profile">
  <reg name="r0" bitsize="32"/>
  <reg name="r1" bitsize="32"/>
  <reg name="r2" bitsize="32"/>
  <reg name="r3" bitsize="32"/>
  <reg name="r4" bitsize="32"/>
  <reg name="r5" bitsize="32"/>
  <reg name="r6" bitsize="32"/>
  <reg name="r7" bitsize="32"/>
  <reg name="r8" bitsize="32"/>
  <reg name="r9" bitsize="32"/>
  <reg name="r10" bitsize="32"/>
  <reg name="r11" bitsize="32"/>
  <reg name="r12" bitsize="32"/>
  <reg name="sp" bitsize="32" type="data_ptr"/>
  <reg name="lr" bitsize="32"/>
  <reg name="pc" bitsize="32" type="code_ptr"/>
  <reg name="xpsr" bitsize="32"/>

  <!-- System registers below.  Note these are not
       _required_ by org.gnu.gdb.arm.m-profile.   -->
  <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>

It'll work just as well.  GDB will display the registers just fine.

IOW, if you're not sure, it probably means no, you don't need the
new feature.

(BTW, features put under the "org.gnu.gdb" namespace must all
be documented in the gdb's manual.)

That said, if multiple projects want it, I guess it wouldn't hurt to
put an official xml file in the gdb tree, just so everyone has a
canonical place to copy the file from.

>>> 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. 

Can you clarify?  What stubs would those be?  Since GDB has no built-in
knowledge of these registers, when debugging against stubs that don't
sent a target description, there's no way they would ever be presented.

> 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).

I meant things like Linux/ptrace, where a non-privileged
userspace debugger normally can't access system/privileged registers.
Even though m-profile targets the microcontroller space, there's a
Linux port that runs on it, for example.

So getting back to the original question:

> 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?

If you asking about gdb's copy of the files, the answer is neither.
Leave those alone for stubs that don't have access to the system
registers.

We'd instead need a new file arm-m-system.xml that lists the system
registers and then a new arm-with-m-system.xml wrapper file that is like
arm-with-m.xml but also xi:includes arm-m-system.xml.  Something like:

$ diff -up arm-with-m.xml arm-with-m-system.xml
 <!DOCTYPE target SYSTEM "gdb-target.dtd">
 <target>
   <architecture>arm</architecture>
   <xi:include href="arm-m-profile.xml"/>
+  <xi:include href="arm-m-system.xml"/>
 </target>

Then stubs pick either arm-with-m-system.xml or arm-with-m.xml
depending on access to the system registers.

Thanks,
Pedro Alves