Discrepancy in register name info between OpenOCD and GDB-MI

[yunuscukran]

Hi,

I am building a VSCode debugger for RISC-V cores, based on https://github.com/Marus/cortex-debug. I have managed to change its settings so that it uses riscv-gdb and riscv-openOCD. It is successfully connecting to my OpenTitan Verilator simulation.

The stack is VSCode -> cortex-debug ( which itself is a extension of VSCode's Native Debug extension) -> GDB- MI Interface -> OpenOCD -> Device. I am using this extension because of the flexibility it gives me in configuring gdb-openOCD connections.

I think the problems I am having stem from the fact that this cortex-debugger is using the GDB-MI interface, and the outputs of that interface do not always match what openOCD returns.

To display its registers, this debugger uses the GDB-MI command data-list-register-names, and the output I believe is the whole of possible 4162 registers a RISC-V processor could have. This is from the debug console:

Meanwhile, when I actually look into the log of what openOCD is doing, I see the following output. (I have run openOCD's reg command independently and verified that the outputs match). So the debugger is at some point calling openOCD's riscv_get_gdb_reg_list_internal() function, but this is being ignored for that previous list that GDB-MI returns instead. This output shows a much smaller set of registers.

The debugger tries to read all the values from the bigger list, and because some do not exist, it fails.

GDB-MI has other commands for reading the registers, and they don't cause problems. I have tested these and if a register exists in openOCD's reg output, and if it has a value, the read will work. In other words, GDB-MI and OpencOCD will act consistently when reading register values. It is getting the list of register names that is the problem.

Is this discrepancy expected because this debugger was built for ARM cores? Are there any plans or expectations that GDB-MI and openOCD should return consistent register names for a RISC-V chip?

[timsifive]

I'm not really familiar with gdb-mi, but I believe that Eclipse uses it so it must at least be possible to make things work. I'm surprised that it finds the full list of registers that OpenOCD knows about internally. The XML is intentionally limited, because if I expose all the registers there then Eclipse crashes. Where does gdb-mi get its register list from?

[yunuscukran]

So far I've only found this piece of documentation, I will look into where it's getting that big list from:

Source: https://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_223.html

For clarification: does OpenOCD reg interact with that intentionally smaller XML? At first, I thought it was getting some device-specific info regarding the register names.

[yunuscukran]

This naming issue may also be related to the reading problem, as seen in lowRISC/opentitan#3097

The failure happens both when calling GDB-MI's data-list-register-values and GDB's info reg all.

In both cases, they fail at register ft0. I also managed to get OpenOCD's log during the failure. That ft0 - fpr0 name difference seemed suspicious to me, but I don't know.

OpenOCD's log during that failiure:

Debug: 45896 913969 gdb_server.c:3373 gdb_input_inner(): received packet: 'T1'
Debug: 45897 913969 gdb_server.c:404 gdb_put_packet_inner(): sending packet '$OK#9a'
Debug: 45898 913970 gdb_server.c:3373 gdb_input_inner(): received packet: 'p21'
Debug: 45899 913970 riscv.c:1672 riscv_get_gdb_reg_list_internal(): rtos_hartid=0, current_hartid=0, reg_class=0, read=0
Debug: 45900 913970 riscv.c:3051 riscv_set_current_hartid(): setting hartid to 0, was 0
Debug: 45901 913970 riscv.c:3209 riscv_get_register_on_hart(): [riscv.tap.0]{0} fpr0 does not exist.
Debug: 45902 913970 gdb_server.c:1320 gdb_get_register_packet(): Couldn't get register ft0.
Debug: 45903 913970 gdb_server.c:1413 gdb_error(): Reporting -4 to GDB as generic error
Debug: 45904 913970 gdb_server.c:404 gdb_put_packet_inner(): sending packet '$E0E#ba'