Initial implementation of an interactive debugger, RDB

[donofrio]

This is a first cut at an interactive command line debugger for rev. Currently it has been tested with one core / one hart. Multicore will probably work... multihart is for sure broken.

To drop into debugging you set a param on RevCPU "breakAtCycle" : <cycle number> An example is the python config. Once in, you are greeted with a command prompt. h will get you help:

Supported commands:
        reg <hart> <num>  // Print Register value. num >= 32 will print all regs
        s <num>           // Step forward num cycles - default is one cycle
        pc <hart> <num>   // Execute until hart reaches pc == num. num must be in hex
        c                 // Continue (exit debugger)

Still in draft as there are some fundamental design choices worth considering before this goes further - for example, is RevCPU the right place for this class to live, or should it have some functionality buried in an individual RevProc as well, or should there be a debugger instance per Proc, rather than a single global debugger per RevCPU? Currently RDB is a friend of RevProc, so it can read / write any or all of it's internal state.

Some potential feature targets:

• Break on a memory address touch
• Read memory
• Integration with Tracer output (auto print tracer output when you single step)
• Call stack printout
• Others?

[leekillough]

reg <hart> <num> // Print Register value. num >= 32 will print all regs

It would be more intuitive if simply omitting <num> printed all registers.

pc <hart> <num> // Execute until hart reaches pc == num. num must be in hex

It would be good if hex/decimal/octal were supported by reading 0x... as hex, 0... as octal, and 123... as decimal (strtol with a base of 0, or %i in scanf).

[kpgriesser]

I like the idea of enabling the tracer. In addition to enabling the tracer at the breakpoint we could capture a limited size trace buffer and dump it when we hit a breakpoint.

[jleidel]

can we close this PR?