GDB register name confusion

[Tommy Murphy]

Hi there

If I run GDB, connect to my RV32IM target and view registers I get this:

i r
ra             0x800002b4 2147484340
sp             0x80002d10 2147495184
gp             0x80001fe0 2147491808
tp             0x0000012d 301
t0             0x8000003c 2147483708
t1             0x05809068 92311656
t2             0x40844110 1082409232
fp             0x80002d40 2147495232
s1             0x00000000 0
a0             0x00000001 1
a1             0x80002d40 2147495232
a2             0x80001ca0 2147490976
a3             0x00000000 0
a4             0x80001d64 2147491172
a5             0x80002d40 2147495232
a6             0x00000006 6
a7             0x00000000 0
s2             0x00000001 1
s3             0x60001ee3 1610620643
s4             0x80000fdf 2147487711
s5             0xa0000009 2684354569
s6             0x10000102 268435714
s7             0x00350940 3475776
s8             0x21100300 554697472
s9             0x21242000 556015616
s10            0x000004e0 1248
s11            0x00000218 536
t3             0x46000610 1174406672
t4             0x00001200 4608
t5             0x01000200 16777728
t6             0x84804840 2222999616
pc             0x80001534 2147489076

Questions:

1. Why doesn't it list x0/zero notwithstanding the fact that it's a fixed 0x00000000 register?
2. Doesn't list any FP regs which is correct for this RV32IM target - if it was, say, RV32IMF would it show the FP regs?
3. Doesn't list any CSRs - why not?

If I run GDB in GDB/MI mode (riscv64-unknown-elf-gdb -i mi) and ask for the register names I get this (I've truncated the output in two places with ellipses due to the length of the full output - 13699 characters

-data-list-register-names
^done,register-names=["x0","x1","x2","x3","x4","x5","x6","x7","x8","x9","x10","x11","x12","x13","x14","x15","x16","x17","x18","x19","x20","x21","x22","x23","x24","x25","x26","x27","x28","x29","x30","x31","pc","f0","f1","f2","f3","f4","f5","f6","f7","f8","f9","f10","f11","f12","f13","f14","f15","f16","f17","f18","f19","f20","f21","f22","f23","f24","f25","f26","f27","f28","f29","f30","f31","csr0","csr1","csr2","csr3","csr4","csr5","csr6","csr7","csr8","csr9","csr10","csr11","csr12","csr13","csr14","csr15","csr16","csr17","csr18","csr19","csr20","csr21","csr22","csr23","csr24","csr25","csr26","csr27","csr28","csr29","csr30","csr31","csr32","csr33","csr34","csr35","csr36","csr37","csr38",
...
"csr4051","csr4052","csr4053","csr4054","csr4055","csr4056","csr4057","csr4058","csr4059","csr4060","csr4061","csr4062","csr4063","csr4064","csr4065","csr4066","csr4067","csr4068","csr4069","csr4070","csr4071","csr4072","csr4073","csr4074","csr4075","csr4076","csr4077","csr4078","csr4079","csr4080","csr4081","csr4082","csr4083","csr4084","csr4085","csr4086","csr4087","csr4088","csr4089","csr4090","csr4091","csr4092","csr4093","csr4094","csr4095","priv","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",
...
"","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",""]

Questions:

1. Why doesn't it use readable ABI rather than less meaningful canonical names for all regs (e.g. zero instead of x0, ra instead of x1, sp instead of x2 etc.)?
2. Is there any way to force GDB to return ABI rather than canonical register names?
3. Why does it return reg names not relevant to the target - e.g. in the case of RV32IM all the FP regs and most of the CSRs? Perhaps gdb should be "tunable" via the architecture (and maybe other info?) to know what specific registers are relevant in a particular situation? I seem to recall somebody posting about this before but can't recall/find the info now and am not sure if something like this was slated at any stage?
4. Why does it return a whole bunch of "blank" reg names at the end of the list?
5. As far as I know only a small subset of CSRs are actually implemented so does it make sense to return the full list of 4096 names?

As it happens Eclipse/CDT interfaces to GDB using GDB/MI so the CDT register view ends up with this humongous list of register names and only canonical names which makes it difficult to understand what's going on when debugging.

If any more info is needed let me know.

Thanks

Tommy

[Stefan O'Rear]

On Wed, Apr 26, 2017 at 3:04 PM, Tommy Murphy <tommy_...@hotmail.com> wrote:
> Hi there
>
> If I run GDB, connect to my RV32IM target and view registers I get this:
>
> i r
>

> Questions:
>
> Why doesn't it list x0/zero notwithstanding the fact that it's a fixed
> 0x00000000 register?
> Doesn't list any FP regs which is correct for this RV32IM target - if it
> was, say, RV32IMF would it show the FP regs?
> Doesn't list any CSRs - why not?

(gdb) help i r
List of integer registers and their contents, for selected stack frame.
Register name as argument means describe only that register.
(gdb) help i all-registers
List of all registers and their contents, for selected stack frame.
Register name as argument means describe only that register.

-s

[Tommy Murphy]

Thanks Stefan - that's useful.

I never thought of RTFH(elp)! My mistake... :-)

I'm still curious about the other issues if anybody else has any comments on them.

And the general question of if the de facto RISC-V support in GDB needs generalisation to cater for an arbitrary RISC-V target architecture/implementation so that it can return the relevant register list (and ideally use ABI rather than raw canonical names)?

[Tommy Murphy]

Another question...

When I use info all-reg as per Stefan's post below it gives a list of registers using readable/ABI names but I cannot correlate the CSR names to the latest (?) draft v1.9.1 privileged spec (https://riscv.org/specifications/privileged-isa/) so where do these CSR register names come from?

E.g.

fflags         0xffffffff RD:7 NV:1 DZ:1 OF:1 UF:1 NX:1  
frm            0xffffffff FRM:3 [RUP (Round up towards +?)]
fcsr           0xffffffff RD:7 NV:1 DZ:1 OF:1 UF:1 NX:1   FRM:3 [RUP (Round up towards +?)]
sstatus        0xffffffff -1
sie            0xffffffff -1
stvec          0xffffffff -1
scounteren     0xffffffff -1
sscratch       0xffffffff -1
sepc           0xffffffff -1
scause         0xffffffff -1
sbadaddr       0xffffffff -1
sip            0xffffffff -1
sptbr          0xffffffff -1
mstatus        0x00001800 SD:0 VM:00 MXR:0 PUM:0 MPRV:0 XS:0 FS:0 MPP:3 HPP:0 SPP:0 MPIE:0 HPIE:0 SPIE:0 UPIE:0 MIE:0 HIE:0 SIE:0 UIE:0
misa           0xffffffff RV128ABCDEFGHIJKLMNOPQRSTUVWXYZ
medeleg        0x00000000 0
mideleg        0x00000000 0
mie            0x00000000 0
mtvec          0x8000003c -2147483588
mcounteren     0xffffffff -1
mucounteren    0xffffffff -1
mscounteren    0xffffffff -1
mhpmevent3     0xffffffff -1
etc.

[Stefan O'Rear]

On Thu, Apr 27, 2017 at 4:49 AM, Tommy Murphy <tommy_...@hotmail.com> wrote:
> Another question...
>
> When I use info all-reg as per Stefan's post below it gives a list of
> registers using readable/ABI names but I cannot correlate the CSR names to
> the latest (?) draft v1.9.1 privileged spec
> (https://riscv.org/specifications/privileged-isa/) so where do these CSR
> register names come from?
> E.g.

Except for mhpmevent3 ( which is
https://github.com/riscv/riscv-isa-manual/blob/master/src/machine.tex#L1404
) I think all of those names are in 1.9.1?

-s

[Tommy Murphy]

I didn't post the full list because it's so long but there are many CSRs listed that are not in the draft 1.9.1 priv spec.

And even those that nearly match are not identical in name for some reason (e.g. sstatus here is ustatus in the spec etc.).

It's quite confusing... Is there some earlier or later draft spec that the GDB register list might be based on or something?

[Stefan O'Rear]

On Thu, Apr 27, 2017 at 2:54 PM, Tommy Murphy <tommy_...@hotmail.com> wrote:
> I didn't post the full list because it's so long but there are many CSRs
> listed that are not in the draft 1.9.1 priv spec.
> And even those that nearly match are not identical in name for some reason
> (e.g. sstatus here is ustatus in the spec etc.).

What makes you think that?

sstatus is in the 1.9.1 spec. (§4.1.1, p.47)

No register named "ustatus" is in any version of the spec. (there is
a *reserved name and number*, but if you look closely there's nothing
corresponding to §4.1.1 for ustatus)

-s

[Tommy Murphy]

Table 2.2 in the 1.9.1 draft priv spec lists ustatus as CSR 0x000

[Stefan O'Rear]

On Thu, Apr 27, 2017 at 3:11 PM, Tommy Murphy <tommy_...@hotmail.com> wrote:
> Table 2.2 in the 1.9.1 draft priv spec lists ustatus as CSR 0x000

What that table is telling you is that *if* a CSR named ustatus is
ever added (it hasn't,
https://github.com/riscv/riscv-isa-manual/issues/16), then it will use
ID 0x000 in implementations that support it (which will not be all of
them; ustatus is earmarked for the N extension).

-s

[Tommy Murphy]

OK - thanks Stefan - my mistake in my misreading of the draft spec.

Is there a draft 1.10 anywhere?

I can't seem to find it.

[Tommy Murphy]

FWIW I've logged a few issues against riscv-binutils-gdb on some of these points:

https://github.com/riscv/riscv-binutils-gdb/issues

For now I am hacking GDB locally so that GDB/MI returns ABI names for integer, FP and CSR registers (in my case the draft priv spec 1.9 CSR names/numbers because that's what I'm using at the moment).