This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Decoding morello instructions to determine the faulting memory address on a SIGPROT

We're porting OpenJDK purecap to Morello (CHERI-BSD and potentially linux if we get time). The si_addr field of siginfo_t contains the faulting PC address (on CHERI), but for implicit null checks we need to determine the faulting memory address - this needs to be evaluated to see if it is less than one page in size - if so we invoke a handler stub. Our interpreter works reasonably robustly and we have C1 JIT running moderate complexity benchmarks with deoptimization but this is a real problem for us ATM.

On AArch64 - such faults would be SIGSEGV and the si_addr would contain the memory address causing the fault. 

Can anyone point me to sources that would enable us to decode the instruction (preferably the faulting memory address) - we have the ucontext_t - so we have the register values etc .. I'm guessing such code is present somewhere in OS/binutils. 

Thanks,

Andy

Parents
  • Hi Andy,

    Having seen your question on CHERI-CPU Slack - it looks like (Morello) Linux and CheriBSD do things differently. There is no separate signal for capability faults on Linux. SIGSEGV is used, and they are handled exactly in the same way as any other data abort. That means notably that the fault address is set to the value of FAR_EL1 (see here), which is the address causing the data abort, i.e. the address of the memory you are trying to load/store in your case. So I suppose the answer is simply: no decoding needed!

    Cheers,
    Kevin

Reply
  • Hi Andy,

    Having seen your question on CHERI-CPU Slack - it looks like (Morello) Linux and CheriBSD do things differently. There is no separate signal for capability faults on Linux. SIGSEGV is used, and they are handled exactly in the same way as any other data abort. That means notably that the fault address is set to the value of FAR_EL1 (see here), which is the address causing the data abort, i.e. the address of the memory you are trying to load/store in your case. So I suppose the answer is simply: no decoding needed!

    Cheers,
    Kevin

Children
No data