[PATCH 0/6] Fix unwinding through sigreturn trampolines

Dave Martin Dave.Martin at arm.com
Tue Jun 23 05:54:19 EDT 2020

On Tue, Jun 23, 2020 at 09:54:30AM +0100, Will Deacon wrote:
> Hi all,
> This series fixes unwinding through our 64-bit sigreturn trampoline (by
> effectively removing the incomplete CFI support enabled during the merge
> window) and the 32-bit sigreturn trampoline in the compat vDSO (by removing
> it in favour of the sigpage). This forces the unwinder to fallback on the
> heuristics it was using previously without any reported issues.
> The downside is that this series undoes the LLVM unwinder support added
> during the merge window, in favour of not regressing libgcc. Although Ard
> and I tried very hard to make this all work with CFI, it became obvious
> that it's not 5.8 material, particularly as testing this stuff is extremely
> difficult and appears to be fragile on other architectures too. For example,
> trying to unwind out of a SIGCANCEL handler triggered from within a leaf
> function with pthread cleanup handlers stacked further up in the callchain
> doesn't appear to work at all when compiling with -fexceptions, and works
> partially (invoking a subset of the handlers...) if you reduce the
> optimisation level.
> The compat vDSO changes are a result of me auditing our 32-bit sigreturn,
> realising the compat vDSO trampoline is broken and then deciding that we
> may as well just use the sigpage unconditionally, like arch/arm/ does.
> Thanks to Ard for wasting a significant chunk of his weekend on this mess.
> Patches 1-4 are targetting 5.8, the remaining two are cosmetic.

In the longer term, we should perhaps keep .cfi_signal_frame, and ditch
all the other annotations.  If the unwinder knows for sure it's the
signal frame (and understands this annotation), it can use its own
knowledge to do the right thing.  Otherwise, it can fall back on its
other heuristics.

This is probably better than having rich annotations that are
pedantically correct, but only half-supported by unwinders out in the

(Just my view)


More information about the linux-arm-kernel mailing list