OpenOCD/GDB Support

[TimMThomas]

Hi everyone, i wanted to ask if support for openocd/gdb or an interactive debug mode (similar to spike) exists, or is maybe planned? I found that feature quite useful, when adding custom functionality to spike. Cheers

[Alasdair]

If you mean something like spike -d, I think that maybe wouldn't be too hard to implement.

I had some GDBMI support in Sail in the past, but that was for a rather esoteric use case where I would run Qemu until I hit a breakpoint in Linux or some other code, then swap the execution from Qemu to the Sail interpreter at that point, so it probably isn't what you want.

[TimMThomas]

If you mean something like spike -d, I think that maybe wouldn't be too hard to implement.

Something like that, yes. When i find the time, i can look into it myself but currently im sadly busy with a lot of other things. Might take a while

[rsnikhil]

I have some code that may be useful in implementing gdb control of the Sail simulator (open-source, Apache license):

https://github.com/bluespec/RISCV_gdbstub

At Bluespec, Inc., we use this for GDB control of our own simulators. Briefly, it works like this:

                                +--------------+
+-----+                         |    gdbstub   |
| gdb | <--remote connection--> | front | back | <--> RISC-V CPU and Memory
+-----+                         |  end  |  end |
                                +--------------+

Notes

• 'gdb' is standard gdb (configured for the RISC-V ISA)

• 'remote connection' is a standard Unix connection (TCP, pipe, ...)

• The remote connection carries messages back and forth according to gdb's RSP (Remote Serial Protocol)

    https://sourceware.org/gdb/current/onlinedocs/gdb.html/Remote-Protocol.html
  

• 'front end' parses incoming RSP messages from gdb and formats outgoing RSP messages to gdb, and converts them into 'API' calls to the back end, such as 'read/write register', 'read/write memory', 'continue', 'step', 'abort (^C)', etc.

• The supplied 'back end' converts these API calls into standard RISC-V Debug Module 'DMI' requests/responses.

For the Sail simulator, one would simply replace the back end API implementation with direct functions to read/write registers, read/write memory, start/stop simulation, ... etc. (Note: this will not need OpenOCD or a RISC-V Debug Module, which are unnecessary extra steps when controlling a simulator).

gdbstub needs to be multiplexed with the main simulation thread (because it has to listen for gdb messages while simulation is running). This can be done either with a separate pthread or by calls within the main simulation loop.

I don't have the time at the moment to do this work, but I'll be happy to answer any questions and provide help (I wrote this code).

[bacam]

I did some work on a general gdb interface for Sail generated C simulators for a different architectural model (loosely based on a prototype Prashanth did for risc-v). Unfortunately I didn't have time to generalize it for other models but I would like to return to it at some point in the future.

[billmcspadden-riscv]

Something else that should be pointed out (for completeness sake)...

Carl Friedrich Bolz-Tereick did some interesting work for improving the performance of Sail models using JIT techniques (See: https://drive.google.com/file/d/1DPftls6lgj6xCLC9n-siyb5sVkE_r3hl/view?usp=sharing )

In the course of this work, he built a python interface that allows a scripting interface to the model. This would allow an interface to be built for gdb, I think. Or, you can use the python interface directly with the interpreter.

Bill Mc.

On Tue, Apr 23, 2024 at 2:53 PM Brian Campbell @.***> wrote:

I did some work on a general gdb interface for Sail generated C simulators for a different architectural model (loosely based on a prototype Prashanth did for risc-v). Unfortunately I didn't have time to generalize it for other models but I would like to return to it at some point in the future.

— Reply to this email directly, view it on GitHub https://github.com/riscv/sail-riscv/issues/453#issuecomment-2073319895, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXROLOCUBDK7P5Z43OOWLPDY6235NAVCNFSM6AAAAABGLLCXBOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZTGMYTSOBZGU . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Bill McSpadden Formal Verification Engineer RISC-V International mobile: 503-807-9309