Re: [Qemu-devel] [RFC] qemu-system-arm: cortex-m gdb registers

["Alex Bennée" <alex.bennee@linaro.org>]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 14 December 2015 at 14:22, Christopher Friedt <chrisfriedt@gmail.com> wrote:
>> On Mon, Dec 14, 2015 at 8:16 AM, Christopher Friedt
>> <chrisfriedt@gmail.com> wrote:
>>> On Mon, Dec 14, 2015 at 8:14 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
>>>> Note that our XML files are from gdb itself, so you should start
>>>> by checking whether gdb has a suitable Cortex-M xml file.
>>>
>>> They do indeed. Thanks for the tip.
>>
>> binutils-gdb arm-m-profile.xml: https://goo.gl/hpTye8
>> openocd armv7m.c: http://goo.gl/FFn56X
>>
>> There are 2 (major) differences from what I've seen:
>>
>> 1) xpsr is regnum 25 instead of 16 (what OpenOCD uses), and I'm fine with that.
>> 2) binutils-gdb does not specify anything for the
>> org.gnu.gdb.arm.m-system group of core registers in any xml file.
>>
>> It also seems very clear that the binutils people and the openocd
>> people have diverged at some point in their assignment of regnum
>> values; in openocd, the registers are mostly all consecutive with
>> moderate reuse between cores, whereas in binutils-gdb, their are
>> occasional gaps and extensive reuse between cores. The differences
>> seem primarily technical, but it's unclear as to why binutils-gdb does
>> *not* include the m-system group of core registers.
>
> My guess would be because gdb is primarily thinking of itself
> as a user-mode debugger, and system registers aren't accessible
> from there. And/or "nobody asked for it".
>
>> The m-system group of core registers are *incredibly* useful, but I'm
>> also inclined not to clobber binutils-gdb's register numbering
>> convention.
>>
>> I think it would be most ideal to append the crucial m-system
>> information directly [1] in arm-m-profile.xml from binutils-gdb (or
>> possibly declare it as an include [2]):
>>
>> <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>
>>
>> However, if the worry there is that it diverges from binutils-gdb,
>> then the next best solution would be to create a separate
>> arm-m-system.xml, and to append that to the cpu->gdb_reg linked list
>> in cortex_m3_initfn(), cortex_m4_initfn(), and any other m's [3].
>>
>> Which solution would work best for qemu?
>
> I'd rather we didn't diverge from upstream gdb too. On the
> other hand I'm not sure how much it matters if we all end up
> using different XML to describe the same target hardware. It
> would be nice to ask the gdb folks first though, maybe.
>
> rth: do you know how this stuff works?

IIRC last time I played with this when adding aarch64 system registers
for debugging is the number is irrelevant to gdb, its all dependant on
what the stub sends. As long as the coprocessor get/set functions agree
on the order with the xml everything should be fine.

>
> thanks
> -- PMM


--
Alex Bennée