The debugger support uses the PRE_SYNC to hold execution of the first instruction until after a debugger allows the target to run.

However, the check for PRE_SYNC happens after the instruction fetch and decode. This is problematic because A) a debugger cannot gain control if the first fetch results in a TLM error and B) a debugger cannot be used to load an image into memory without the core first fetching an incorrect instruction.

Consider creating a new sync point for the debugger before fetch_ins is called.

When attaching the debugger it seems that two single-steps are required to actually single step the first instruction.

Turning on verbose debug, the first single-step results in a memory read (finish read_mem(). The second-single step results in actual instruction execution.

Not a showstopper as it seems to be useable, just a bit confusing.

When the trap handler (MTVEC) resides at an address that returns a TLM error, the debugger will lose control of the session.

Specifically we end up in a loop where the vm detects the instruction fetch error and tries to enter the trap handler.

        if(fetch_ins(pc, data)!=iss::Ok){
            this->do_sync(POST_SYNC, std::numeric_limits<unsigned>::max());
            pc.val = super::core.enter_trap(std::numeric_limits<uint64_t>::max(), pc.val, 0);

the trap handler sets a new value for the next PC which causes execution to loop endlessly attempting trap handling.

As execution goes, this seems reasonable. But for the debugger interface we need a way to interrupt execution to see the state of the processor when in this looping trap handler state.

For the debugger we expect:

1. When single-stepping the PC will advance to the trap handler address but not fetch the trap handler (yet)
2. When running the debugger needs to be able to break execution, showing a PC value of the trap handler

When the debugger attempts to disassemble around the PC at the trap handler address it will get TLM errors and handle these appropriately.

I know rv64gc is still a work in progress but I wanted to document known issues here

The following opcodes appear in vm_rv64gc.cpp but are considered RV32-only instructions:

C__FLW
C__FSW
C__FLWSP
C__FSWSP

the corresponding rv64gc instructions that should be implemented in their place are:

C__LD
C__SD
C__LDSP
C__SDSP