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

Julian Lettner via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 25 13:02:24 PST 2019

Thanks, got it!

> On Feb 25, 2019, at 12:26 PM, Ben Craig <ben.craig at ni.com> wrote:
> 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/828488e5/attachment.html>

More information about the llvm-dev mailing list