On Fri, 23 Jan 2026 09:23:02 GMT, Kevin Walls <[email protected]> wrote:
> Yes, the bytes were Linux x64 specific. I was thinking that the check would > be in a file that is platform/arch specific, and would check for the specific > signal return method for that architecture. However the bytes might be different - where does signal trampoline comes from (libc, vDSO), how is it implemented (whether `mov $0xf, %rax` is always come first) > If we do this with symbol names, or by looking at the bytes, it looks odd to > have a generic method in the symtab file or LinuxCDebugger/LinuxDebuggerLocal > that recognises a signal return method from any platform. AFAICS name of signal trampoline is `__restore_rt`, `__kernel_sigreturn`, or `__kernel_rt_sigreturn` on AMD64 / AArch64. They do not have architecture-dependent string. Thus I defined it in LinuxDebugger.java, and I will use it in other CFrame implementation like LinuxAArch64CFrame. I think it is not so complex because we just add a new name to `LinuxDebugger.SIGHANDLER_NAMES`, and tweak how can we get register values in each CFrame implementation like LinuxAMD64CFrame if we want to support new architecture. I want to support DWARF on both AMD64 and AArch64. Thus I make change carefully we can separate DWARF parser easily in near future. (I will start it after few patches - add support for frameless function and vDSO) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29023#issuecomment-3789774825
