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

[Peter Maydell]

On 14 December 2015 at 14:22, Christopher Friedt <address@hidden> wrote:
> On Mon, Dec 14, 2015 at 8:16 AM, Christopher Friedt
> <address@hidden> wrote:
>> On Mon, Dec 14, 2015 at 8:14 AM, Peter Maydell <address@hidden> 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?

thanks
-- PMM