After [JDK-8377946](https://bugs.openjdk.org/browse/JDK-8377946), we can see 
test failure on ClhsdbPstack.java. But the failure was happened before 
[JDK-8377946](https://bugs.openjdk.org/browse/JDK-8377946) - test is passed, 
but we can see the exception and the function symbol was not been resolved. 
(You can see .jtr files in JBS)

`DwarfParser` should scan `.eh_frame` first. but `.debug_frame` should be 
scanned as fallback if target PC was not found in `.eh_frame`.

According to [System V ABI for 
AMD64](https://refspecs.linuxbase.org/elf/x86_64-abi-0.99.pdf), frame 
information should be included in .eh_frame (See 6.3 Unwinding Through 
Assembler Code)

In musl C, I found out the discussion for .eh_frame vs .debug_frame: 
https://www.openwall.com/lists/musl/2021/07/17/13
musl C does not seem to want to support `.eh_frame` - they seem to want to use 
`.debug_frame` for stack unwinding in debugging. But it could be different from 
ABI spec in above.

This PR is not small, but commit history might help to review.

- [Use lib->base 
directly](https://github.com/openjdk/jdk/commit/319e1b85d278bad90caeb5b13c41a0f4ca81cb00)
 - remove unnecessary field from `eh_frame_info`.
- [Move debuginfo related code to salibelf from 
symtab](https://github.com/openjdk/jdk/commit/0682a312f8202592e2ad6bc2210b27f5190c4ce0)
 - as a preparation for `.debug_frame`, debuginfo related code is needed for 
this PR, but it is written in symtab.c. So moved it to another file 
(salibelf.c).
- [Rename "eh_frame_info" to 
"frame_info"](https://github.com/openjdk/jdk/commit/662b373f316eeb920dc7b6a0df155a5b7c852ef1)
 - frame information in SA is no longer for `.eh_frame`, so renamed.
- [Use .debug_frame if DWARF parser could not find PC from 
.eh_frame](https://github.com/openjdk/jdk/commit/0e4477ac9bc95026283c1ad085c1bbb43b399ef0)
 - implement DWARF parser for `.debug_frame`.
- [Validate sender SP before to return sender frame in 
LinuxAMD64CFrame.java](https://github.com/openjdk/jdk/commit/ec4a08d3d4457c1bb70bb1a73e9978fd018eab1a)
 -
current `LinuxAMD64CFrame` might enter infinity loop not to find out bottom 
frame (I saw this case on Alpine), thus add condition for frame validation with 
stack pointer.
- [Re-enable mixed jstack tests on musl 
C](https://github.com/openjdk/jdk/commit/de27835d7ae58bc7547f25fefe1613af47757c82)
 - as stated in the commit message.
- [Update copyright 
year](https://github.com/openjdk/jdk/commit/2dc4f1dfa101f511a0305ede04aed027eb87c1f0)
 - as stated in the commit message.

Note that all of mixed jstack tests have been disabled on Alpine (musl C) since 
[JDK-8382327](https://bugs.openjdk.org/browse/JDK-8382327). They are re-enabled 
in this PR.

---------
- [x] I confirm that I make this contribution in accordance with the [OpenJDK 
Interim AI Policy](https://openjdk.org/legal/ai).

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

Commit messages:
 - Update copyright year
 - Re-enable mixed jstack tests on musl C
 - Validate sender SP before to return sender frame in LinuxAMD64CFrame.java
 - Use .debug_frame if DWARF parser could not find PC from .eh_frame
 - Rename "eh_frame_info" to "frame_info"
 - Move debuginfo related code to salibelf from symtab
 - Use lib->base directly

Changes: https://git.openjdk.org/jdk/pull/30815/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30815&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8382392
  Stats: 649 lines in 14 files changed: 321 ins; 280 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/30815.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/30815/head:pull/30815

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

Reply via email to