[llvm-dev] [Sanitizers] Platforms that don't support stack unwinding

[Ben Craig via llvm-dev]

Existence of unwind information is a runtime property.  It is possible for a given binary to have zero unwind information.  The easiest example is a 32-bit x86 Windows binary (and maybe Linux?) built with frame-pointer-omission.  There are no unwind tables in that situation, and you can't just follow frame pointers backwards, because they don't exist.  This kind of unwinding generally requires debug information.  Maybe, in some specific cases, you could analyze the assembly to figure out how to unwind it, but in the general case, that requires solving the halting problem.

Embedded platforms often omit all unwinding information to save space.

If you have a recent instruction pointer from user code, then just reporting that one instruction pointer can still be useful.

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Julian Lettner via llvm-dev
Sent: Monday, February 25, 2019 1:30 PM
To: llvm-dev at lists.llvm.org
Subject: [EXTERNAL] [llvm-dev] [Sanitizers] Platforms that don't support stack unwinding

Hi,

In sanitizer code we have two notions of stack unwinders: fast and slow. [1] In the context of sanitizers, stack unwinding is most often for printing error reports that include a stack trace.

I am currently trying to fix an issue that is related to some platforms (Darwin) only supporting the fast unwinder, but calling code not being aware of that possibility.
My mental model was that platforms are required to at least support one kind of unwinder, so I turned a runtime check [2] into a compile time assert [3]. Apparently this is not the case.

What do (or should) we do on platforms without supported unwinders?
Or is my mental model correct, and this a runtime (instead of compile time) check for other reasons? Compilation/build system convenience?

Thanks,
Julian

[1] https://github.com/llvm/llvm-project/blob/fcbd7f64953b04f42dd59f606e45dc8e88a27548/compiler-rt/lib/sanitizer_common/sanitizer_stacktrace.h#L21<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_llvm_llvm-2Dproject_blob_fcbd7f64953b04f42dd59f606e45dc8e88a27548_compiler-2Drt_lib_sanitizer-5Fcommon_sanitizer-5Fstacktrace.h-23L21&d=DwMFAg&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=PyWoz5dhVQq4Qd3o66DlXu836tgSHFc2XCX0gHQyHoM&s=xPhup1hvHzIkL7yBEi03pLgh3ntvnZwqBzo-n-KzrMc&e=>
[2] https://github.com/llvm/llvm-project/blob/fcbd7f64953b04f42dd59f606e45dc8e88a27548/compiler-rt/lib/sanitizer_common/sanitizer_stacktrace_libcdep.cc#L78<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_llvm_llvm-2Dproject_blob_fcbd7f64953b04f42dd59f606e45dc8e88a27548_compiler-2Drt_lib_sanitizer-5Fcommon_sanitizer-5Fstacktrace-5Flibcdep.cc-23L78&d=DwMFAg&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=PyWoz5dhVQq4Qd3o66DlXu836tgSHFc2XCX0gHQyHoM&s=Y3jCglxBAPEjTrHwT0YsdIFdEsfw8LLkKWs4YUxxH70&e=>
[3] https://github.com/llvm/llvm-project/blob/fcbd7f64953b04f42dd59f606e45dc8e88a27548/compiler-rt/lib/sanitizer_common/sanitizer_stacktrace.h#L21<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_llvm_llvm-2Dproject_blob_fcbd7f64953b04f42dd59f606e45dc8e88a27548_compiler-2Drt_lib_sanitizer-5Fcommon_sanitizer-5Fstacktrace.h-23L21&d=DwMFAg&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=PyWoz5dhVQq4Qd3o66DlXu836tgSHFc2XCX0gHQyHoM&s=xPhup1hvHzIkL7yBEi03pLgh3ntvnZwqBzo-n-KzrMc&e=>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190225/99468bee/attachment.html>