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

[Ben Craig via llvm-dev]

If the target is almost always memory constrained, implementing an (optional) unwinder may be considered not worth the effort.  AVR microprocessors typically have less than a megabyte worth of storage available.  Getting your “regular” program to fit is often pretty challenging.  Getting an unwinder and UBSan and unwinding information would be even more challenging.  “Only” getting UBSAN (or ASAN) without unwinding information is still valuable in these situations.

So you could consider it an oversight, but an unwinder in these kinds of platforms probably wouldn’t get used much.

From: jlettner at apple.com <jlettner at apple.com>
Sent: Monday, February 25, 2019 2:09 PM
To: Ben Craig <ben.craig at ni.com>
Cc: llvm-dev at lists.llvm.org; Vitaly Buka <vitalybuka at google.com>; Richard Trieu <rtrieu at google.com>
Subject: [EXTERNAL] Re: [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<mailto: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<mailto: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<mailto: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/70af62e6/attachment.html>