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 I have examined how GDB operates; this is not necessarily an authoritative conclusion. GDB 18.1 follows this workflow: 1. Read the original frame PC using get_frame_pc(). 2. Choose the lookup address using get_frame_address_in_block(): - Ordinary caller return address → PC−1. - Top-frame or signal-restored execution PC → exact PC. 3. Select the FDE using that lookup address. 4. Interpret the CFI rules up to the same address, using fs->pc <= pc. PC−1 is a lookup adjustment; it does not replace the original frame PC. get_frame_address_in_block() // gdb/frame.c:2855–2904, see the comments ... if ((get_frame_type (next_frame) == NORMAL_FRAME || get_frame_type (next_frame) == TAILCALL_FRAME) && (get_frame_type (this_frame) == NORMAL_FRAME || get_frame_type (this_frame) == TAILCALL_FRAME || get_frame_type (this_frame) == INLINE_FRAME)) return pc - 1; return pc; ... dwarf2_frame_find_fde execute_cfa_program // The interpreter uses an inclusive comparison (gdb/dwarf2/frame.c:257) while (insn_ptr < insn_end && fs->pc <= pc) ... My RISC-V implementation follows the same principle: exact PCs for top/signal-restored frames, and PC−1 lookup for ordinary native caller frames. ------------- PR Comment: https://git.openjdk.org/jdk/pull/33374#issuecomment-6361761846
