Core Register names as per ISA specs? about riscv-openocd

[timsifive]

OpenOCD's reg command (as used from the telnet interface) shows x0--x31.

It would be ideal to display/accept the symbolic names, while still accepting x0--x31.

[ilg-ul]

OpenOCD's reg command (as used from the telnet interface) shows x0--x31.

I think this is one of the problems, that your expected use case is calibrated for manual usage.

In Eclipse there are several views, with different information. One is the Disassembly view, where register names use the ABI convention. Another one is the Registers view, where registers currently have the x%d names. If I try to identify the content of the registers refered in the assembly view, I need to open a separate browser with the ABI table, which is very awkward.

In other words, the list of registers shown in the Registers view must use the same convention as the Disassembly view (the ABI convention).

If I remember right, in QEMU the register names were defined in an XML file, passed to GDB during initialisation, then Eclipse got these names from GDB.

I did not study the OpenOCD implementation, but I guess something similar happens here; somehow you pass a list of names from OpenOCD (as a GDB server) to the GDB client.

My suggestion is to make this list use the ABI names, the rest should be ok in GDB and indirectly in Eclipse.

It would be ideal to display/accept the symbolic names, while still accepting x0--x31.

If 'still accepting x0--x31' pertains only to the manual OpenOCD interface, feel free to use any naming conventions you want; I'm only interested in consistency in the Eclipse views.

[timsifive]

I believe that the RISC-V register names are hardcoded in gdb, and are not transmitted from OpenOCD using the XML file mechanism. But I don't have a thorough understanding on how everything gets its names.

The use case I'm focusing on is gdb, assuming that if gdb works well then tools built on top of gdb will also work well. info registers in gdb does show symbolic names.

[ilg-ul]

From the point of view of the Eclipse General Registers view, once GDB is fixed via riscvarchive/riscv-binutils-gdb#111, this issue can be closed. I'm not sure if register names shown by monitor reg use the GDB names, or the definitions are local, and in this case need to be updated separately.

[ilg-ul]

the RISC-V register names are hardcoded in gdb

poor choice. :-(

ARM GDB gets the register names from the GDB server.

how does GDB know the core type, to display or not the FP registers? in the example I know, QEMU knows the core type, and in ARM case, passes different XMLs, with or without FP registers.

I see no reason for OpenOCD not to use the same approach.

[timsifive]

I agree that having OpenOCD pass an XML file to gdb would be better. ISTR looking at it and couldn't find any documentation or clear example on how that is supposed to work.

[ilg-ul]

that if gdb works well then tools built on top of gdb will also work well

Eclipse uses the MI interface, not the manual interface.

couldn't find any documentation or clear example on how that is supposed to work.

yes, documentation is probably inadequate. did you also check the linux gdbserver? the XML passing may be used there too.

[ilg-ul]

for reference, here is a link to the file I modified in QEMU: https://github.com/gnu-mcu-eclipse/qemu/blob/gnuarmeclipse-dev/gdb-xml/arm-cortexm.xml

[ilg-ul]

and, as the comment mentions, the same XML mechanism is used by SEGGER JLinkGDBserver.

[palmer-dabbelt]

Yes, we know about the XML mechanism and it's the right thing to do. This was brought up as part of the GDB upstreaming process, I just haven't had time to look at it.

[ilg-ul]

ok, then I suggest to keep this ticket open and check again how register names reach Eclipse when the XML mechanism is functional.

[ilg-ul]

riscvarchive/riscv-binutils-gdb#73

[TommyMurphyTM1234]

FWIW I made a (very inelegant! :-) hack to GDB's riscv-tdep.c (attached - renamed to riscv-tdep.c.txt because *.c files won't upload for some reason) so that ABI rather than canonical names are returned. For the moment I build GDB with this hack until such time as there is a proper solution using the target description XML mechanism which I hope to look at and maybe produce a strawman mod. Note that in draft priv spec "only" c. 200 of the possibly 4096 CSRs are implemented/allocated. It would be an improvement if the relevant register commands returned only these rather than all 4096 possible regs. (Even then do users really need ANY CSRs every time?).

I think that using the GDB target description XML mechanism it may be possible to support different register sets based on the target architecture (deduced from misa or other CSRs or else passed via GDB's set architecture command). E.g. ABI names for the following:

• if E extension then integer regs x0-x15 otherwise all integer regs x0-x31
• if G/F/D/Q extension then floating point regs fp0-fp31 otherwise none of these
• only CSRs actually implemented/allocated in the latest priv spec (may be further tunable based on target capabilities?)
• pc and priv always implemented/returned
  riscv-tdep.c.txt

[aka-sps]

See https://github.com/riscv/riscv-openocd/blob/riscv/src/target/register.h#L120-L121

struct reg {
	/* Canonical name of the register. */
	const char *name;
     ...
};

Canonical names are: x##, f##, csr#### (see ISA spec).

Typically gdb defines own ABI aliases for canonical names. The reverse is not true.

If you want to use "pretty" ABI names in OpenOCD, you can define TCL variables:

> set s0 x8
x8
> set fp x8
x8
> reg $fp
x8 (/32): 0xF00004E8
> reg $s0
x8 (/32): 0xF00004E8

Revert your changes, please.