GDB server doesn't support processor-specific CSRs about renode

[mszprejda]

In our setup we are able to inspect registers with (gdb) p/x $mie and (gdb) p/x $mtvec. There is however a discrepancy between the addressing that we are using and the configuration that we found in the code you linked. We will look into it.

[xobs]

Here's what I get when I do info all when connecting to a VexRiscv CPU in hardware, via wishbone-tool:

(gdb) info all
zero           0x0      0
ra             0x17dc   0x17dc <trap_entry+72>
sp             0x1001ff60       0x1001ff60
gp             0x0      0x0 <_start>
tp             0x0      0x0 <_start>
t0             0x19f8   6648
t1             0x1000009c       268435612
t2             0x10000090       268435600
fp             0x1      0x1 <_start+1>
s1             0xe0008000       -536838144
a0             0x0      0
a1             0xe0005000       -536850432
a2             0x40     64
a3             0x40     64
a4             0xe0005000       -536850432
a5             0x1      1
a6             0x100000c4       268435652
a7             0x40     64
s2             0x0      0
s3             0x10000000       268435456
s4             0x10000000       268435456
s5             0x10000000       268435456
s6             0x10000000       268435456
s7             0x10000000       268435456
s8             0x0      0
s9             0x0      0
s10            0x0      0
s11            0x0      0
t3             0x10000090       268435600
t4             0x10000098       268435608
t5             0x50     80
t6             0x0      0
pc             0x1540   0x1540 <isr+44>
satp           0x0      0
mstatus        0x1880   SD:0 VM:00 MXR:0 PUM:0 MPRV:0 XS:0 FS:0 MPP:3 HPP:0 SPP:0 MPIE:1 HPIE:0 SPIE:0 UPIE:0 MIE:0 HIE:0 SIE:0 UIE:0
mie            0x880    2176
mtvec          0x0      0
mscratch       0x0      0
mepc           0x1388   5000
mcause         0x8000000b       -2147483637
mtval          0x0      0
mip            0x800    2048
mcycle         0x162e6808       372140040
minstret       0x8e00a40        148900416
mcycleh        0x0      0
minstreth      0x0      0
mvendorid      0x0      0
marchid        0x0      0
mimpid         0x0      0
mhartid        0x0      0
(gdb)

Note that, for example, I can see $mcycle is something that is sane. And I can see that $mcause in this hardware CPU is set to 0x8000000b.

Contrast this with Renode, where registers cannot be inspected that way:

(gdb) p/x $mcause
$3 = 0x0
(gdb) mon cpu MCAUSE
0x8000000b
(gdb)

[mateusz-holenko]

Right now when you read p/x $mcause in Renode you probably just receive a default value (0) of a not-known register.

Extending Renode’s target.xml with the set of CSRs compatible with wishbone-tool should not be complicated - I’ll look into this.

[mithro]

@mateusz-holenko - You probably want to return a target.xml which matches the current CPU architecture -- IE it'll be different for SiFive, picorv32, VexRISCV configurations, etc.

[xobs]

You'll also want to make registers disappear and reappear depending on the current register set. For example, when running with RISCV_PRIV_1.10, you'll want $satp, but under RISCV_PRIV_1.09 you'll want to expose $sbtpr.

[mateusz-holenko]

Thanks to the contribution of @evolentini there is now an infrastructure for defining GDB features, including the CPU registers list.

The next step is to enable this support for various kinds of RISC-V cores.

[mateusz-holenko]

Listing and support for custom CSRs for RISC-V should now work with the current Renode.

[PiotrZierhoffer]

Closing as done