RFR: 8302384: Handle hsdis out-of-bound logic for RISC-V [v3]

[Xiaolin Zheng]

> Several debug assertion failures have been observed on RISC-V, on physical boards only.
> 
> Failure list: (the `hs_err` log is in the JBS issue)
> 
> compiler/vectorapi/TestVectorShiftImm.java
> compiler/compilercontrol/jcmd/AddPrintAssemblyTest.java
> compiler/intrinsics/math/TestFpMinMaxIntrinsics.java
> compiler/compilercontrol/TestCompilerDirectivesCompatibilityFlag.java
> compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOn.java
> compiler/runtime/TestConstantsInError.java
> compiler/compilercontrol/jcmd/PrintDirectivesTest.java
> 
> 
> When the failure occurs, hsdis is disassembling the last unrecognizable data at the end of a code blob, usually the data stored in trampolines. It could be theoretically any address inside the code cache, and sometimes binutils can recognize the data as 2-byte instructions, 4-byte instructions, and 6 or 8-byte instructions even though as far as I know no instructions longer than 4-byte have landed. Therefore, binutils may firstly run out of bound after the calculation. However, the RISC-V binutils returns our `hsdis_read_memory_func`'s return number directly [1] (an EIO, which is `5`, FYI), rather than returning a `-1` (FYI, [2][3][4][5]) on other platforms when such out-of-bound happens. So when coming back to our hsdis, we (hsdis) get the `size = 5` as the return value [6] rather than `-1`: our hsdis error handling is skipped, our variable `p` is out of bound, and then we meet the crash.
> 
> To fix it, we should check the value is the special `EIO` on RISC-V. However, after fixing that issue, I found binutils would print some messages like "Address 0x%s is out of bounds." on the screen:
> 
> 
> 0x0000003f901a41b4:   auipc	t0,0x0                      ;   {trampoline_stub}
> 0x0000003f901a41b8:   ld	t0,12(t0) # 0x0000003f901a41c0
> 0x0000003f901a41bc:   jr	t0
> 0x0000003f901a41c0:   .2byte	0x8ec0
> 0x0000003f901a41c2:   srli	s0,s0,0x21
> 0x0000003f901a41c4:   Address 0x0000003f901a41c9 is out of bounds.      <----------- But we want the real bytes here.
> 
> 
> So, we should overwrite the `disassemble_info.memory_error_func` in the binutils callback [7], to generate our own output:
> 
> 0x0000003f901a41b4:   auipc	t0,0x0                      ;   {trampoline_stub}
> 0x0000003f901a41b8:   ld	t0,12(t0) # 0x0000003f901a41c0
> 0x0000003f901a41bc:   jr	t0
> 0x0000003f901a41c0:   .2byte	0x8ec0
> 0x0000003f901a41c2:   srli	s0,s0,0x21
> 0x0000003f901a41c4:   .4byte	0x0000003f
> 
> 
> Mirroring the code of hsdis-llvm, to print merely a 4-byte data [8].
> 
> 
> BTW, the reason why the crash only happens on the physical board, is that boards support RISC-V sv39 address mode only: a legal user-space address can be no more than 38-bit. So the code cache is always mmapped to an address like `0x3fe0000000`. Such a `0x3f` is always recognized as the mark of an 8-byte instruction [9].
> 
> 
> Tested hotspot tier1~4 with fastdebug build, no new errors found.
> 
> Thanks,
> Xiaolin
> 
> 
> [1] https://github.com/bminor/binutils-gdb/blob/binutils-2_38-branch/opcodes/riscv-dis.c#L940
> [2] https://github.com/bminor/binutils-gdb/blob/binutils-2_38-branch/opcodes/aarch64-dis.c#L3792
> [3] https://github.com/bminor/binutils-gdb/blob/binutils-2_38-branch/opcodes/ppc-dis.c#L872
> [4] https://github.com/bminor/binutils-gdb/blob/binutils-2_38-branch/opcodes/s390-dis.c#L305
> [5] https://github.com/bminor/binutils-gdb/blob/binutils-2_38-branch/opcodes/i386-dis.c#L9466 (the i386 one uses a `setlongjmp` to handle the exception case, so the code might look different)
> [6] https://github.com/openjdk/jdk/blob/94e7cc8587356988e713d23d1653bdd5c43fb3f1/src/utils/hsdis/binutils/hsdis-binutils.c#L198
> [7] https://github.com/bminor/binutils-gdb/blob/binutils-2_38-branch/opcodes/dis-buf.c#L51-L72
> [8] https://github.com/openjdk/jdk/blob/94e7cc8587356988e713d23d1653bdd5c43fb3f1/src/utils/hsdis/llvm/hsdis-llvm.cpp#L316-L317
> [9] https://github.com/bminor/binutils-gdb/blob/binutils-2_38-branch/include/opcode/riscv.h#L30-L42

Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:

  Remove white spaces, and use hsdis code style

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12551/files
  - new: https://git.openjdk.org/jdk/pull/12551/files/64ec1ed5..a43caa65

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12551&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12551&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12551.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12551/head:pull/12551

PR: https://git.openjdk.org/jdk/pull/12551