Invalid branch address exceptions

[cinco...@gmail.com]

Spec says branch exception "reported on the target inst". But csr epc description says "written with virtual address of the inst that was interrupted..." So, we have a branch that tries to branch to an invalid address. If we put the bogus target address in the epc, then how can we find the bad branch inst? If the put address of branch in epc, that seems to contradict the "on next inst" statement. Or, do we put address following the branch inst, that seems to contradict "reported on the target".  What is correct behavior? 

[Andrew Waterman]

The sentence you quoted refers specifically to exceptions that result from the act of fetching the branch target.  The way to think about it is, the exception isn't associated with the branch at all; indeed, the branch successfully retires.  The exception is associated with the fetch of the next instruction in program order.  So, epc _does_ point to the exceptional instruction.

Re: "then how can we find the bad branch inst" -- indeed, the exception reporting mechanism does not provide this information.

On Tue, Jul 19, 2022 at 7:47 AM cinco...@gmail.com <cinco...@gmail.com> wrote:

Spec says branch exception "reported on the target inst". But csr epc description says "written with virtual address of the inst that was interrupted..." So, we have a branch that tries to branch to an invalid address. If we put the bogus target address in the epc, then how can we find the bad branch inst? If the put address of branch in epc, that seems to contradict the "on next inst" statement. Or, do we put address following the branch inst, that seems to contradict "reported on the target".  What is correct behavior? 

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/0202a1c1-df23-495e-9c4a-7c0e1a87fa8en%40groups.riscv.org.

[Allen Baum]

This is actually a very good question, in that the answer isn't obvious or trivial. 

Unpriv section 2.3 says: 

     An instruction-address-misaligned exception is generated on a taken branch or unconditional jump if the target address is not IALIGN-bit aligned. 

     This exception is reported on the branch or jump instruction, not on the target instruction.

Unpriv section 2.5 says: 

     If an instruction access-fault or instruction page-fault exception occurs on the target of a jump or taken branch,
     the exception is reported on the target instruction, not on the jump or branch instruction. 

So, 2 different cases. But, note that 2 kinds of information can be stored:

The xEPC CSR will save either the address of the jump/branch, or the address of the target, as above.

But xTVAL CSR can (optionally) save other  exception specific information

Priv section 3.1.16 says:

If mtval is written with a nonzero value 
when a breakpoint, address-misaligned, access-fault, or page-fault exception occurs on an instruction fetch, load, or store, 
       then mtval will contain the faulting virtual address (note that in bare mode, virtual==physical)
when a misaligned load or store causes an access-fault or page-fault exception, 
      then mtval will contain the virtual address of the portion of the access that caused the fault. 
      (note that "portion" could be the effective address, or if it was misaligned, the address of the half that failed)
on an illegal instruction exception  
      then mtval can optionally also be used to return the faulting instruction bits (details of which bits are returned is in the spec)
      (note that the latter case is different because the the faulting instruction bits can be all zero)

On Tue, Jul 19, 2022 at 7:47 AM cinco...@gmail.com <cinco...@gmail.com> wrote:

Spec says branch exception "reported on the target inst". But csr epc description says "written with virtual address of the inst that was interrupted..." So, we have a branch that tries to branch to an invalid address. If we put the bogus target address in the epc, then how can we find the bad branch inst? If the put address of branch in epc, that seems to contradict the "on next inst" statement. Or, do we put address following the branch inst, that seems to contradict "reported on the target".  What is correct behavior? 

--

[Allen Baum]

To add to what Andrew said: you asked about a branch to an invalid address, 

but that could be interpreted as a misaligned address, or an address for which the program does not have a page mapping, 

or does, but doesn't have execute permissions, or even an illegal instruction .

Different cases have different results. You need to be specific about what is written to the  xCAUSE CSR to know which.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2B%2B6G0AvN6Yh5RfL5hm%2Bm8s_EVOhheukLDaH%3DoCPT1Fe-%2BD1tA%40mail.gmail.com.

[MitchAlsup]

Adding::

When you transfer control due to a branch or jump and the Fetch address is ill-formed,

the exception is reported on the instruction transferring control. In this case, there is

no reasonable target address for FETCH.

When you transfer control due to a branch or jump and the Fetch address is well-formed,

any exception is reported on the target of the control transfer instruction. In this case, there 

is a reasonable target address for FETCH, but there was something wrong with the memory 

the target address points at.