Julian Lettner via llvm-dev
2019-Feb-25 19:29 UTC
[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://github.com/llvm/llvm-project/blob/fcbd7f64953b04f42dd59f606e45dc8e88a27548/compiler-rt/lib/sanitizer_common/sanitizer_stacktrace.h#L21> [2] https://github.com/llvm/llvm-project/blob/fcbd7f64953b04f42dd59f606e45dc8e88a27548/compiler-rt/lib/sanitizer_common/sanitizer_stacktrace_libcdep.cc#L78 <https://github.com/llvm/llvm-project/blob/fcbd7f64953b04f42dd59f606e45dc8e88a27548/compiler-rt/lib/sanitizer_common/sanitizer_stacktrace_libcdep.cc#L78> [3] https://github.com/llvm/llvm-project/blob/fcbd7f64953b04f42dd59f606e45dc8e88a27548/compiler-rt/lib/sanitizer_common/sanitizer_stacktrace.h#L21 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190225/32341fab/attachment.html>
Ben Craig via llvm-dev
2019-Feb-25 19:42 UTC
[llvm-dev] [Sanitizers] Platforms that don't support stack unwinding
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>
Julian Lettner via llvm-dev
2019-Feb-25 20:09 UTC
[llvm-dev] [Sanitizers] Platforms that don't support stack unwinding
Thank you for the explanation, Ben! I realized I didn’t give enough context for my question: As you noted, the slow/fast unwinder can only do its work if there is enough (runtime) information. Otherwise stack printing usually does exactly what you suggested: printing the one frame corresponding to the recent pc. When I asked if “platforms are required to at least support one kind of unwinder” I meant: Shouldn’t there be at least an implementation for one kind of unwinder on each platform (so that in the presence of runtime information, they can do their work). Phrased differently: isn’t a platform not having an unwinder implementation an oversight?> On Feb 25, 2019, at 11:42 AM, 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/b9d09a20/attachment.html>