On Mon, 19 Oct 2026 03:45:10 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 incrementally with one additional > commit since the last revision: > > Enable TestJhsdbJstackMixedWithXComp.java on riscv64 while excluding QEMU > environments > > I guess older toolchain for RISC-V generates DWARF into `.debug_frame` if > > we need `-fasynchronous-unwind-tables`. I've created PR for it as #33375 . > > It might be better to wait and to test it after that. I expect your PR > > works without ` -fasynchronous-unwind-tables` after that. > > Thanks, @YaSuenag! I tried #33375 together with this PR on RISC-V hardware > with GCC 12.3.1, which doesn't enable unwind tables by default. You're right > that the CFI then goes to `.debug_frame`, and with the `.debuginfo` files > next to the libraries all threads unwind to `thread_native_entry` and the > mixed jstack tests pass. > > However, with the default `--with-native-debug-symbols=external`, release > builds don't put the `.debuginfo` files into images/jdk (only into > images/symbols). With images/jdk, unwinding stops at the first libjvm frame , > and `TestJhsdbJstackMixedCore` fails because the crashing thread stops at > `os::abort`. The same applies to the release bundles and to > `--with-native-debug-symbols=none/zipped`. So I think we still need > `-fasynchronous-unwind-tables` on riscv64; it only matters for GCC < 13 and > Clang < 17, since newer compilers enable it by default. Thank you for the verification in [#33375](https://github.com/openjdk/jdk/pull/33375). Given that `.debuginfo` files may not be released or installed, I think adding the `-fasynchronous-unwind-tables` option is acceptable. However, we also need to accept that the size of shared libraries will grow. ------------- PR Comment: https://git.openjdk.org/jdk/pull/33374#issuecomment-6259242129
