Re: [PATCH v4.1 06/10] x86/entry/vdso32: remove open-coded DWARF in sigreturn.S
From: Xi Ruoyao
Date: Mon Feb 09 2026 - 23:46:19 EST
On Mon, 2026-02-09 at 20:15 -0800, H. Peter Anvin wrote:
> On February 9, 2026 7:11:25 PM PST, Xi Ruoyao <xry111@xxxxxxxxxxx> wrote:
> > On Mon, 2026-02-02 at 19:57 -0800, H. Peter Anvin wrote:
> > > That hack dates back from before the signal frame extension. It is no
> > > longer necessary.
> >
> > Unfortunately at least it seems libgcc unwinder does not handle the
> > signal frame extension properly. The code reads:
> >
> > fde = _Unwind_Find_FDE (context->ra + _Unwind_IsSignalFrame (context) - 1,
> > &context->bases);
> > if (fde == NULL)
> > {
> > #ifdef MD_FALLBACK_FRAME_STATE_FOR
> > /* Couldn't find frame unwind info for this function. Try a
> > target-specific fallback mechanism. This will necessarily
> > not provide a personality routine or LSDA. */
> > return MD_FALLBACK_FRAME_STATE_FOR (context, fs);
> > #else
> > return _URC_END_OF_STACK;
> > #endif
> > }
> >
> > fs->pc = context->bases.func;
> >
> > cie = get_cie (fde);
> > insn = extract_cie_info (cie, context, fs);
> >
> > Thus, it indeed attempts to avoid subtracting 1 for a signal frame, but
> > ... _Unwind_IsSignalFrame (context) actually extracts a flag in context
> > which will only be raised up by extract_cie_info.
> >
> > Or am I missing something here?
> >
>
> 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.
--
Xi Ruoyao <xry111@xxxxxxxxxxx>