Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Alan-19950616 opened this issue May 21, 2024 · 10 comments

Comments

@Alan-19950616
Copy link

Alan-19950616 commented May 21, 2024

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
Copy link
Collaborator

TommyMurphyTM1234 commented May 21, 2024

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:

For some related discussion see also here:

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

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

@fanghuaqi
Copy link
Contributor

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
Copy link
Collaborator

TommyMurphyTM1234 commented May 24, 2024

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.

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
Copy link
Contributor

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:

image

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

image

@TommyMurphyTM1234
Copy link
Collaborator

TommyMurphyTM1234 commented May 24, 2024

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
Copy link
Contributor

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
Copy link
Collaborator

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
Copy link
Collaborator

en-sc commented May 24, 2024

@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
Copy link
Collaborator

@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.

@fanghuaqi
Copy link
Contributor

@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.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants