On Mon, 2026-02-09 at 20:51 -0800, H. Peter Anvin wrote:
> On 2026-02-09 19:11, Xi Ruoyao 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?
> > 
> 
> Well, it looks like this might be a non-manifest bug on x86 *IN THIS CASE*,

But only if after the patch _Unwind_Find_FDE returns NULL here (instead
of a FDE of another function).  I've not verified it on x86.  If glibc
tests (specifically misc/tst-sigcontext-get_pc) work fine things should
be fine.

/* snip */

> Could you file a gcc bug on this?

Will do.


-- 
Xi Ruoyao <[email protected]>

Reply via email to