Re: How can I figure out the register numbers for a remote target stub?

[Simon Marchi <simark@simark.ca>]

Hi Sebastian,

I am a bit confused myself with register numbering, so I will try to answer
your question to the best of my knowledge without sending you on a wrong track.
Perhaps Yao in CC can clarify, since he works quite a lot on regcaches.

On 2017-11-29 05:53 AM, Sebastian Huber wrote:
> Sorry for the bad format in the previous mail. Here is the next attempt:
> 
> I would like to extend the RTEMS GDB remote target stub to support 
> PowerPC (e500, e6500).  In the ARM support we have some magic register 
> numbers:
> 
> https://git.rtems.org/rtems/tree/cpukit/libdebugger/rtems-debugger-arm.c#n132 
> 
> 
> /*
>   * Debugger registers layout.
>   */
> #define REG_R0 0
> #define REG_R1 1
> #define REG_R2 2
> #define REG_R3 3
> #define REG_R4 4
> #define REG_R5 5
> #define REG_R6 6
> #define REG_R7 7
> #define REG_R8 8
> #define REG_R9 9
> #define REG_R10 10
> #define REG_R11 11
> #define REG_R12 12
> #define REG_SP 13
> #define REG_LR 14
> #define REG_PC 15
> #define REG_CPSR 25
> 
> How can I find the corresponding numbers for the PowerPC? There is a 
> comment in (gdb/ppc-tdep.h):
> 
> /* Register number constants. These are GDB internal register numbers; 
> they are
>   * not used for the simulator or remote targets. Extra SPRs (those 
> other than
>   * MQ, CTR, LR, XER, SPEFSCR) are given numbers above PPC_NUM_REGS. So are
>   * segment registers and other target-defined registers. */
> enum {
>    PPC_R0_REGNUM = 0,
>    PPC_F0_REGNUM = 32,
> 
> I cannot find the numbers which are used for remote targets. Are they 
> defined by the XML files in gdb/features/rs6000?

You can use the command "maintenance print raw-registers" at any time to see
the format of the raw register buffer expected by GDB.  The output also includes
the register number (not sure which one).  For example:

(gdb) set architecture powerpc:e500
The target architecture is assumed to be powerpc:e500
(gdb) maintenance print raw-registers
 Name         Nr  Rel Offset    Size  Type            Raw value
 r0            0    0      0       4 uint32_t        <invalid>
 r1            1    1      4       4 uint32_t        <invalid>
 r2            2    2      8       4 uint32_t        <invalid>
...
 pc           64   64    128       4 *1              <invalid>
 msr          65   65    132       4 uint32_t        <invalid>
 cr           66   66    136       4 uint32_t        <invalid>
 lr           67   67    140       4 *1              <invalid>
 ctr          68   68    144       4 uint32_t        <invalid>
 xer          69   69    148       4 uint32_t        <invalid>
...

The offsets and sizes indicate the format of the expected reply to the
g packet.  Watch out though, for some reason the
"maintenance print raw-registers" command lists the cooked registers at
the end:

...
 ev0         174    0    292       8 ppc_builtin_type_vec64 <cooked>
...

Those registers should not be included in the response to the 'g' packet.

Those numbers seem to match the numbers in ppc-tdep.h, I suppose that's
not a coincidence.  If you do the same command but for the arm architecture,
the numbers will match the numbering you pasted above.  But it's the part
that really confuses me, there are multiple kinds of register numbers, and
it's not clear to me who assigns them.

Simon