Unaligned memory access with JDK

[Palmer Dabbelt]

On Thu, 28 Jul 2022 13:50:00 PDT (-0700), vladimir.kempik at gmail.com wrote:
> Hello
> I was recently playing with a simple risc-v core running on an fpga and found the idk crashes on it.
> It crashes with SIG_ILL : ILL_TRP, on a simple load from memory instruction.
> So I figured the main issue is unaligned memory access MacroAssembler::stop() and that risc-v core was pretty simple and didn’t support unaligned memory access.
> Here is what I found:
>
> void MacroAssembler::stop(const char* msg) {
>   const char * msg1 = ((uint64_t)msg) & ~0x07 + 0x08;
>   BLOCK_COMMENT(msg1);
>   illegal_instruction(Assembler::csr::time);
>   emit_int64((uintptr_t)msg1);
> }
>
> and emit_64 is :
>   void emit_int64( int64_t x)  { *((int64_t*) end()) = x; set_end(end() + sizeof(int64_t)); }
>
> the problem is that the end() pointer is shared between emit_int64, emit_int32, emit_int8, etc, and non of them do care about natural memory alignment for processed types:
>
>   void emit_int32(int32_t x) {
>     address curr = end();
>     *((int32_t*) curr) = x;
>     set_end(curr + sizeof(int32_t));
>   }
>
>   void emit_int8(int8_t x1) {
>     address curr = end();
>     *((int8_t*)  curr++) = x1;
>     set_end(curr);
>   }
>
> So my question is - risc-v cores without unaligned memory access support - are they supported by risc-v openjdk port ?

Support for misaligned accesses lives in a weird grey area in RISC-V: 
misaligned accesses used to be mandated by the ISA, but that requirement 
was removed in 2018 via 61cadb9 ("Provide new description of misaligned 
load/store behavior compatible with privileged architecture.").  I just 
sent a patch to document this, looks like we never bothered to write it 
down (probably because nobody was watching for the ISA change).

That said, some implementations support misaligned accesses via a M-mode 
trap handler, as implementations can do essentially anything they want 
in RISC-V.  IIUC most of the RISC-V OpenJDK port was done on systems 
that have hardware support for misaligned accesses, but even on systems 
that trap to M-mode the port should function correctly -- sure it'll be 
slow, but the support should otherwise be transparent to userspace (and 
even to Linux).  It might be worth fixing that performance issue, but if 
you're seeing a SIGILL from a misaligned access then there's likely also 
a functional bug in the emulation routines or Linux.