On Tue, 7 Apr 2026 12:26:40 GMT, Yasumasa Suenaga <[email protected]> wrote:
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/aarch64/LinuxAARCH64CFrame.java
>> line 160:
>>
>>> 158: fallback = true;
>>> 159: } catch (DebuggerException _) {
>>> 160: if (linuxDbg().isSignalTrampoline(senderPC)) {
>>
>> Is this "We can use the caller frame if it is a signal trampoline." ?
>> LinuxAMD64CFrame.java has the same comment.
>>
>> Looks like we do mean to have this check twice here in LinuxAARCH64CFrame.
>> If we don't find senderDWARF for senderPC or senderPC-1, we return a
>> LinuxAARCH64CFrame based on senderPC IF is a signal trampoline.
>> This one is new compared to LinuxAMD64CFrame.java and looks reasonable.
>
>> Is this "We can use the caller frame if it is a signal trampoline." ?
>
> Yes.
> Signal trampoline is special frame, so we can set sender PC/SP/FP straightly
> without DWARF.
>
>> Looks like we do mean to have this check twice here in LinuxAARCH64CFrame.
>
> As I commented, vdso.so on AArch64 Linux might not have `.eh_frame`, then
> DWARF parser would fail. Thus I added signal trampoline check in L160.
Thanks.
I was thinking if we should make them the same but yes we expect eh_frame on
x64 as I understand, and not on aarch64, and this should be reliable.
These sender methods are similar so it's good to clarify why they are different.
I understand this comment now, I thought it was more general:
// DWARF processing might be fail because vdso.so does not have .eh_frame .
Could it be more specific like:
// DWARF processing might fail because vdso.so .eh_frame is not required on
aarch64
(not "be fail")
Can you make all 3 comments say "We can use the caller frame.." and then I
think you should integrate if no other problems!
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29731#discussion_r3051158581
