On 2026-02-09 20:45, Xi Ruoyao wrote:
>>
>> Oh, good grief...
>>
>> How does this possibly work on non-x86 platforms?
>
> On ARM64 the vdso does not have eh_frame_hdr at all, on LoongArch
> eh_frame_hdr is empty (note that an ampty en_frame_hdr is actually buggy
> and I'm trying to fix it), so _Unwind_Find_FDE returns NULL and libgcc
> falls back to MD_FALLBACK_FRAME_STATE_FOR, which handles the sigreturn
> trampoline using some machine-dependant logic.
>
> On RISC-V things are more theatrical: the sigreturn trampoline happens
> to be at the beginning of the vdso .text section, so after subtracting 1
> from the PC, the result is out of the .text section and so not in any
> FDE. Thus _Unwind_Find_FDE returns NULL and libgcc again falls back to
> MD_FALLBACK_FRAME_STATE_FOR.
>
> If the RISC-V sigreturn trampoline was not the first in .text,
> subtracting 1 would cause the PC to be in the FDE of the previous
> function and then _Unwind_Find_FDE would return that FDE, then RISC-V
> would have some big trouble.
>
> I've not taken a serious look at other architectures yet.
>
In other words, it is broken on pretty much all architectures and it ends up
using the hacky fallbacks on every single platform...
-hpa
