Splits the unwinder into a non-segv (for allocation/deallocation traces) and a
segv unwinder. This ensures that implementations can select an accurate, slower
unwinder in the segv handler (if they choose to use the GWP-ASan provided one).
This is important as fast frame-pointer unwinders (like the sanitizer unwinder)
don't like unwinding through signal handlers.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
compiler-rt/lib/gwp_asan/optional/backtrace_linux_libc.cpp | ||
---|---|---|
30 | I'm probably missing something here... Since this is the same implementation as Backtrace, the whole change seems pointless? |
compiler-rt/lib/gwp_asan/optional/backtrace_linux_libc.cpp | ||
---|---|---|
30 | The libc unwinder doesn't have the problems as it's DWARF based. Scudo prebuilts out of the LLVM tree use this unwinder (so no problems), but Scudo when built from source on other codebases gives us the flexibility to drop in a faster, frame-pointer based unwinder - where this change is necessary. Or, when using the sanitizer unwinder, this change is also necessary to fallback from the FP unwinder to a DWARF unwinder in the segv handler. |
compiler-rt/lib/gwp_asan/optional/backtrace_sanitizer_common.cpp | ||
---|---|---|
71 | Very similar to Backtrace. Let's factor out a helper function that does fast unwind only when Context == nullptr. |
- Refactor the backtrace code into a common core.
compiler-rt/lib/gwp_asan/optional/backtrace_sanitizer_common.cpp | ||
---|---|---|
71 | Done. |
After this change, two gwp-asan tests started failing:
GwpAsan-Unittest :: ./GwpAsan-x86_64-Test/BacktraceGuardedPoolAllocator.DoubleFree GwpAsan-Unittest :: ./GwpAsan-x86_64-Test/BacktraceGuardedPoolAllocator.UseAfterFree
It seems variable names are not symbolized (but the backtrace and function names look fine), and so the death test expectations don't match.
This seems to happen in builds configured with -DCOMPILER_RT_BUILD_BUILTINS=OFF
Can you please take a look? Full error message and reproducer here: https://bugs.chromium.org/p/chromium/issues/detail?id=1107769
I've reverted in ab6263c9258ccd0e3c9cb4f675979f22cfba6131 in the meantime.
I'm probably missing something here... Since this is the same implementation as Backtrace, the whole change seems pointless?