Using the info reg all command within gdb returns an remote failure reply 'E0E'

[Alan-19950616]

These error messages cause the IDE register component to not display properly.

236c54c

This is part of the gdb output:

(gdb) info reg all
......
fflags         0x0      RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0
frm            0x0      FRM:0 [RNE (round to nearest; ties to even)]
fcsr           0x0      RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:0 [RNE (round to nearest; ties to even)]
vstart         0x0      0
vxsat          0x0      0
vxrm           0x0      0
vcsr           0x0      0
seed           Could not fetch register "seed"; remote failure reply 'E0E'
sstatus        0x200000000      8589934592
sedeleg        Could not fetch register "sedeleg"; remote failure reply 'E0E'
sideleg        Could not fetch register "sideleg"; remote failure reply 'E0E'
sie            0x0      0
stvec          0x0      0
scounteren     0x0      0
senvcfg        0x0      0
sscratch       0x0      0
sepc           0x0      0
scause         0x0      0
stval          0x0      0
sip            0x0      0
stimecmp       0xffffffffffffffff       -1
stimecmph      Could not fetch register "stimecmph"; remote failure reply 'E0E'
satp           0x0      0
spmpcfg0       Could not fetch register "spmpcfg0"; remote failure reply 'E0E'
spmpcfg1       Could not fetch register "spmpcfg1"; remote failure reply 'E0E'
spmpcfg2       Could not fetch register "spmpcfg2"; remote failure reply 'E0E'
spmpcfg3       Could not fetch register "spmpcfg3"; remote failure reply 'E0E'
spmpaddr0      Could not fetch register "spmpaddr0"; remote failure reply 'E0E'
spmpaddr1      Could not fetch register "spmpaddr1"; remote failure reply 'E0E'
spmpaddr2      Could not fetch register "spmpaddr2"; remote failure reply 'E0E'
hstatus        Could not fetch register "hstatus"; remote failure reply 'E0E'
hedeleg        Could not fetch register "hedeleg"; remote failure reply 'E0E'
hideleg        Could not fetch register "hideleg"; remote failure reply 'E0E'
hie            Could not fetch register "hie"; remote failure reply 'E0E'
hip            Could not fetch register "hip"; remote failure reply 'E0E'
vstimecmp      Could not fetch register "vstimecmp"; remote failure reply 'E0E'
vstimecmph     Could not fetch register "vstimecmph"; remote failure reply 'E0E'
mstatus        0xa00001800      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           0x800000000034112f       RV64ABCDFIMSUV

[TommyMurphyTM1234]

As far as I know, the Could not fetch register "..."; remote failure reply 'E0E' message is expected for non-existent/unimplemented CSRs. If you want to avoid it or it's causing you problems then you might need to use the riscv hide_csrs ... command:

• target/riscv: hide_csrs configuration option #787

• riscv-openocd/src/target/riscv/riscv.c

  Lines 5101 to 5108 in ac12065

  	.name = "hide_csrs",
  	.handler = riscv_hide_csrs,
  	.mode = COMMAND_CONFIG,
  	.usage = "{n0|n-m0}[,n1|n-m1]......",
  	.help = "Configure a list of inclusive ranges for CSRs to hide from gdb. "
  	"Hidden registers are still available, but are not listed in "
  	"gdb target description and `reg` command output. "
  	"This must be executed before `init`."

For some related discussion see also here:

• Discrepancy in register name info between OpenOCD and GDB-MI #500
• [question/feature] facilities to hide some CSRs from the user #785

These error messages cause the IDE register component to not display properly.

What exactly are you referring to here? What "IDE register component"?

[fanghuaqi]

If these registers are not available, why not automatically hide it, or just return a fixed value just like before. If return a ERROR value like what is handled now, in Eclipse embedded CDT register window the register value will be Could not fetch register "hstatus"; remote failure reply 'E0E' which cause user confused.

[TommyMurphyTM1234]

If these registers are not available, why not automatically hide it

It's explained in the links that I posted previously. There's no obvious/reliable way to determine that certain CSRs are not available - e.g. during OpenOCD's "target examine" process using the misa extension bits etc. Not all optional CSRs are keyed off a RISC-V extension.

• [question/feature] facilities to hide some CSRs from the user #785 (comment)

or just return a fixed value just like before.

When before? That's not a good idea as it makes it look like such CSRs exist when they do not. And arbitrarily masking errors arising from back-end debugging interactions with the target isn't a good idea on my opinion. What happens if the debugger tries to access a CSR that does exist, the operation fails, but OpenOCD masks the error and pretends that it succeeded? Nothing good I would imagine.

If return a ERROR value like what is handled now, in Eclipse embedded CDT register window the register value will be Could not fetch register "hstatus"; remote failure reply 'E0E' which cause user confused.

Even if you use the riscv hide_csrs ... command to hide the unavailable CSRs? E.g. via the relevant target or board specific OpenOCD script?

In my opinion it's at least as confusing/misleading, if not more so, to pretend to the user that some CSRs exist and have some default value when they do not.

[fanghuaqi]

Even if you use the riscv hide_csrs ... command to hide the unavailable CSRs? E.g. via the relevant target or board specific OpenOCD script?

For this, if this CPU is a chip, it will be ok, but if it is a soft-cpu run in FPGA, it will be hard to maintain different configuration files for different soft-cpu configs which may have different csrs exposed, I will prefer just one configuration file for all soft-cpu cores.

This will cause eclipse cdt debug register windows show like this:

Previous version of openocd, will not show so many errors.

[TommyMurphyTM1234]

For this, if this CPU is a chip, it will be ok, but if it is a soft-cpu run in FPGA, it will be hard to maintain different configuration files for different soft-cpu configs which may have different csrs exposed,

In that case it should be possible to arrange for the generation the riscv hide_csrs ... list as an artefact of the FPGA implementation "build" process since all of the information needed is available in/from the HDL implementation?

Previous version of openocd, will not show so many errors.

What specific version?

[fanghuaqi]

In that case it should be possible to arrange for the generation the riscv hide_csrs ... list as an artefact of the FPGA implementation "build" process since all of the information needed is available in/from the HDL implementation?

For our case, it is not possible, this bit generation don't generate openocd configuration files, the openocd config file is just one file stay in the sdk distributed to others.

What specific version?

Our port is based on this commit 5217759

[TommyMurphyTM1234]

For our case, it is not possible, this bit generation don't generate openocd configuration files, the openocd config file is just one file stay in the sdk distributed to others.

I meant that with some work the bitstream generation flow could be extended to extract the necessary info from the HDL implementation from which the riscv hide_csrs ... list and target specific OpenOCD script could be generated.

Our port is based on this commit 5217759

Maybe create a PR that implements the functionality for unimplemented/missing CSRs that you think should be used and it can then be considered/reviewed as normal?

[en-sc]

@fanghuaqi, are you using gdb_report_register_access_error disable in your OpenOCD config?

This functionality was broken by https://review.openocd.org/c/openocd/+/7876.
https://review.openocd.org/c/openocd/+/8228 should fix it, but it is not ready to be merged yet.

However, this does not change the fact that gdb_report_register_access_error disable is a hack -- the error will not be reported when the access to another register (e.g. GPR) fails. I would strongly discourage you from using it.

Please, consider implementing the approach suggested by @TommyMurphyTM1234.

If you wish for OpenOCD config to stay constant, you can use Jim TCL's json extension and parse a JSON file that would specify the list of CSRs to hide in the OpenOCD script.

[TommyMurphyTM1234]

@fanghuaqi, are you using gdb_report_register_access_error disable in your OpenOCD config?

Just to note that disable is the default setting for this option so if that's the preferred option then it doesn't need to be explicitly specified.

• https://openocd.org/doc/html/Server-Configuration.html

[fanghuaqi]

@fanghuaqi, are you using gdb_report_register_access_error disable in your OpenOCD config?

Just to note that disable is the default setting for this option so if that's the preferred option then it doesn't need to be explicitly specified.

• https://openocd.org/doc/html/Server-Configuration.html

Yes, I am using this option's default feature.