GDB register name confusion

151 views
Skip to first unread message

Tommy Murphy

unread,
Apr 26, 2017, 6:04:56 PM4/26/17
to RISC-V SW Dev
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

unread,
Apr 26, 2017, 9:49:48 PM4/26/17
to Tommy Murphy, RISC-V SW Dev
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

unread,
Apr 27, 2017, 6:05:08 AM4/27/17
to RISC-V SW Dev, tommy_...@hotmail.com
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

unread,
Apr 27, 2017, 7:49:58 AM4/27/17
to RISC-V SW Dev
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

unread,
Apr 27, 2017, 3:10:59 PM4/27/17
to Tommy Murphy, RISC-V SW Dev
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

unread,
Apr 27, 2017, 5:54:57 PM4/27/17
to RISC-V SW Dev, tommy_...@hotmail.com
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

unread,
Apr 27, 2017, 6:02:36 PM4/27/17
to Tommy Murphy, RISC-V SW Dev
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

unread,
Apr 27, 2017, 6:11:13 PM4/27/17
to RISC-V SW Dev, tommy_...@hotmail.com
Table 2.2 in the 1.9.1 draft priv spec lists ustatus as CSR 0x000

Stefan O'Rear

unread,
Apr 27, 2017, 6:20:57 PM4/27/17
to Tommy Murphy, RISC-V SW Dev
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

unread,
Apr 28, 2017, 4:57:56 AM4/28/17
to RISC-V SW Dev, tommy_...@hotmail.com
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

unread,
Apr 28, 2017, 12:44:16 PM4/28/17
to RISC-V SW Dev
FWIW I've logged a few issues against riscv-binutils-gdb on some of these points:


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).
Reply all
Reply to author
Forward
0 new messages