Should register handling be tunable to the target architecture?

[TommyMurphyTM1234]

See also

• GDB/MI -data-list-register-names returns 4162 extraneous blank reg names #71
• Could/should GDB/MI -data-list-register-names return ABI rather than canonical names? #72

RISC-V can provide up to 4162 regs

• 32 integer regs
• 32 FP regs
• 4096 CSRs
• pc
• priv

However in some cases some of these are not relevant to some targets - e.g. a target such as RV32IM with no FP capabilities has no FP regs; many of the CSRs are not actually implemented etc.

Should there be a mechanism whereby GDB can be told what the target architecture (and maybe also the applicable priv spec?) so that it can tune its register handling so that, for example, the GDB/MI -data-list-register-names command only returns the names of those registers relevant to the active target?

The set arch riscv:xxx command allows GDB to be told the target architecture but at the moment I think tha this is only used to specify rv32 or rv64 in order to adjust the size used for registers (and other data?).

Perhaps this could be extended to take an arbitrary RISC-V architecture token which could be used to tune how register handling is done?

If you need any more info please let me know.

Thanks
Tommy

[palmer-dabbelt]

There's already a mechanism for this in GDB land, it involves using target description XML files. This was one of the code review comments on our GDB port, but I haven't had time to get around to it yet.

[TommyMurphyTM1234]

Thanks for the reply Palmer.
Perhaps you could post links (to the relevant gdb info and RISC-V gdb port review) if you get a chance?
Thanks a lot.

[palmer-dabbelt]

#40

[TommyMurphyTM1234]

Thanks a lot.

[palmer-dabbelt]

No problem. You're more than welcome to have a crack at fixing the CR comments or adding XML support.

[ilg-ul]

4096 CSRs

I did not check the actual gdb/gdb server code, but I would not include the RISC-V CSRs in the list of regular registers, it makes life harder, at least in Eclipse.

[ilg-ul]

adding XML support.

for adding XML support, I would search for inspiration in the QEMU implementation of the GDB server, it seems ok.

running a debug session in Eclipse with QEMU and taking a look at the GDB trace logs might also be useful.