On Fri, 23 Oct 2026 02:24:47 GMT, Long Yang <[email protected]> wrote:
>> Hi, could I have a review of this patch. This patch fixes >> [JDK-8391637](https://bugs.openjdk.org/browse/JDK-8391637). >> >> Due to my GitHub account settings (Enable Copilot Code Review for all my >> PRs), my previous [PR](https://github.com/openjdk/jdk/pull/33358) had >> Copilot Review enabled by default. I have disabled it and now open this new >> PR, with no changes made to the code. >> >> On `risc-v`, >> [LinuxRISCV64CFrame.sender()](https://github.com/openjdk/jdk/blob/c368bac40e185398fbc40dc4d75a457f7a36f954/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/riscv64/LinuxRISCV64CFrame.java#L70) >> validates only FP alignment, then dereferences FP for SP, link, and return >> address. An aligned arbitrary FP (such as 0x90) can therefore cause >> UnmappedAddressException, and lead to incomplete stack for the target thread. >> >> `aarch64` and `amdf64`already use `dwarf` to unwind native frames, see >> https://github.com/openjdk/jdk/blob/c368bac40e185398fbc40dc4d75a457f7a36f954/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java#L36 >> https://github.com/openjdk/jdk/blob/c368bac40e185398fbc40dc4d75a457f7a36f954/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/aarch64/LinuxAARCH64CFrame.java#L38 >> >> This patch makes `risc-v` to unwind with `dwarf` too. >> >> The `risc-v` version basically has the same design as the `aarch64` version. >> There are also several differences , primarily due to differences in calling >> conventions. Almost every difference is accompanied by an explanatory >> comment. >> >> I have ran tests in `test/hotspot/jtreg/serviceability/sa` on `risc-v` and >> `amd64`, all passed. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Long Yang has updated the pull request with a new target base due to a merge > or a rebase. The pull request now contains nine commits: > > - Merge branch 'master' into fix-8391637 > - Enable TestJhsdbJstackMixedWithXComp.java on riscv64 while excluding QEMU > environments > - Enable -fasynchronous-unwind-tables for linux-riscv64 > - Add try/catch for memory-read exceptions in getSenderFP > - RISC-V: Use compiler-defined macros for DWARF register selection > - Recover caller return addresses across save helpers > - Use the CIE return-address column instead of the hard-coded RA register > - Add comment > - 8391637: On the RISC-V platform, TestJhsdbJstackMixed has a certain > probability of failure "PC - 1" has been introduced by [JDK-8369994](https://bugs.openjdk.org/browse/JDK-8369994). In AMD64, we can see following instructions when disassembling `os::abort()` on GDB: (gdb) disas 0x7f50e1e01f2e, 0x7f50e1e01f34 Dump of assembler code from 0x7f50e1e01f2e to 0x7f50e1e01f34: 0x00007f50e1e01f2e <_ZN2os5abortEbPKvS1_.cold+0>: call 0x7f50e1e01010 <abort@plt> => 0x00007f50e1e01f33: nop End of assembler dump. In native (mixed) call stacks, `os::abort()` calls `abort()`. However PC (RIP) in the call frame of `os::abort()` points `NOP` which is located just after `CALL`. Function size in ELF (`.symtab` section) covered instructions until at 0x7f50e1e01f2e, 0x7f50e1e01f33 was not covered in this case. Thus we need to "PC - 1" to unwind correctly. I'm not familiar with RISC-V ISA, but if the problem what I saw in AMD64 happens on RISC-V, I guess we need to implement similar logic for RISC-V too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/33374#issuecomment-6357178208
