riscv-fast-interrupt
riscv-fast-interrupt copied to clipboard
riscv
dpc treatment
When performing a vectored interrupt its first fetch will be a fetch of a pointer value from some address A. I think it should be possible to set a breakpoint on that address A. Let's here assume that the pointer fetch itself is treated as an instruction fetch (whether it is an instruction or data fetch is another ongoing discussion). In that case an instruction breakpoint with before timing should lead to dpc containing address A in my opinion. A dret instruction can not just perform pc = dpc (as there is no instruction at address A, but a pointer value). I would therefore think that the CLIC spec needs to add a description of required dret behavior similar to the change in behavior for xret instructions as copied here from section 5.4 (where 'x' refers to privilege, not debug):
if (xcause.inhv) //xcause here refers to the cause CSR of the previous privilege
mode
pc := M[xepc] //xepc here refers to the current privilege mode
else
pc := xepc
I think we should then also add a section similar to section '5.6. Changes to xepc CSRs' to describe the 'Changes to dpc CSR' specifically also noting that the location pointed to by dpc might contain a pointer as opposed to an instruction.
Alternatively it could be forbidden to put breakpoints in the vector table, but that would be a quite awkward restriction.
I agree with the suggestion that it should be permissible to set a trigger on a table load. The CLIC spec states that the table load is treated as a load, not an instruction fetch. This is important, as it affects interpretation of the memory access for PMA and PMP checks, caching, etc. So a trigger on the table load would need to be a load trigger (eg, mcontrol.load = 1). In that case, dpc can be set to the table load address, analogously to xepc being set on a trap during table load. In fact, this applies to any entry to debug mode during table load (eg, haltreq). The behaviour of dret also needs to be updated analogously to xret, to check dcsr.prv to determine the privilege level being returned to, and if xinhv for that level is 1, use dpc as the address for resuming the table load instead of the pc to transfer to.
Hi @pashenden , just want to point out that the CLIC spec was recently updated to align with the Zc JT/JALT and the table load is no longer treated as a load.
here is the revision history entry: 04/26/2022 issue #191 - hw vector fetch permission changed to implicit read with execute permission required.
For permissions-checking purposes, the memory access to retrieve the function pointer for vectoring is an implicit read at the interrupt level of the interrupt handler, and requires execute permission; read permission is irrelevant. If there is an access exception on the table fetch, xepc is written with the faulting address. xtval is either set to zero or written with the faulting address.
Does this affect your recent comment?
Thanks @dansmathers. So that means a trigger would have to be an execute trigger (mcontrol.execute = 1).
From TG meeting 2022/5/10: Agreed that it would be useful to set a breakpoint entry on table address, but might not be practical to implement in all systems depending on fetch microarchitecture (do breakpoints check PC values or memory addresses on instruction port?). However, dret should be defined to do the right thing if inhv is set regardless (creating separate issue #239 for this).
If we wanted to avoid optionality then either all systems must allow breakpoints to take effect on table entries, or all systems must ignore them. Either fixed choice involves additional hardware complexity for some set of plausible hardware microarchitectures, so probably best to make an option.
If this is an option, then debug software would determine via discovery mechanism. Option would need to be named for ISA infrastructure.
This decision should align with code-size group decision for table-jump instructions, as feature is very similar.
We have decided to make table fetch require instruction-fetch permissions, and consider implicit vector table reads as instruction fetches, so watchpoints are not active for table-fetch operations. However, watchpoints can be used to detect explicit loads and stores to the table.
TG meeting 2022/7/19: To condense the previous comment: For implicit hardware table reads, whether breakpoints trap on the table read is left as an implementation option. For explicit loads used in software vectoring, watchpoints operate as normal for any load.