RISC-V: add optional architectural trap entry - #2403
Conversation
|
This looks good, but honestly, the |
trying to emulate full-system riscv32 firmware, It simulates SiFive HiFive1 Rev B development board, using the SiFive FE310. QEMU cannot do this, so I thought I could it it with unicorn. |
Sorry I mean why it should not advance PC? |
|
"When a trap is taken into M-mode, mepc is written with the virtual address of the instruction that was so the +4 happens in the m trap handler which happens on the firmware unicorn assumes you have no firmware, so it does it for you, but if you want to emulate the firmware, unicorn should allow you to do the +4 (in the firmware), or more strictly I want to model m-trap handling in riscv itself |
ed1b582 to
795fde3
Compare
RISC-V exceptions currently call
UC_HOOK_INTRand advancepcwithout updating the trap CSRs or jumping tomtvec.This adds an opt-in control:
When enabled on RISC-V,
cpu_handle_exception()calls QEMU's existingriscv_cpu_do_interrupt()before invokingUC_HOOK_INTR. The hook receives the original exception number.The option is disabled by default, so existing RISC-V behavior does not change. Other architectures return
UC_ERR_ARCHwhen the control is used.The new unit test checks that an M-mode
ecallsetspc,mepc,mcause, and the privilege mode. The existingecalltest still checks the default PC-advance behavior.Fixes #2402