[libcxx-commits] [PATCH] D83573: [libunwind] Support for leaf function unwinding.

Thu Sep 17 17:01:47 PDT 2020

rprichard added a comment.

I think these libunwind tests are relying on the signal trampoline having "good enough" unwind info, but AFAIK, that's not the case with the signal trampoline (__kernel_rt_sigreturn) in the AArch64 Linux vDSO. There was a commit recently adjusting .cfi_startproc to let the unwinder find the vDSO's FDE, but then this was quickly reverted. The FDE change allowed libgcc to find the FDE, and that broke glibc pthread cancellation somehow, so the FDE was then removed:

- https://github.com/torvalds/linux/commit/a4eb355a3fdad85d16e4b098e8d56bb28b812ce0
- https://github.com/torvalds/linux/commit/87676cfca14171fc4c99d96ae2f3e87780488ac4

Sometimes the trampoline comes from libc rather than the kernel, though. I know that Bionic only uses the trampoline on AArch64, but I don't know about other libcs.

Apparently, libgcc and gdb, on the other hand, can handle a signal trampoline by examining the instruction(s) that the target PC points at and matching it against the instruction(s) that a signal trampoline is expected to have. They then do an ad hoc unwind of the frame. Apparently libgcc will segfault if the PC to lookup points at non-readable memory.

I think libgcc may have this ad hoc signal frame handling for x86 as well, so if the x86 glibc/vdso trampolines lack FDEs, then that could explain this test's failure on x86.

Aside: this test is assuming Unix -- do we need to disable it for e.g. Windows?

I suspect this change should be temporarily reverted.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83573/new/

https://reviews.llvm.org/D83573