This is an archive of the discontinued LLVM Phabricator instance.

[asan] Disable fast unwinder on arm-linux-gnueabi with thumb
AbandonedPublic

Authored by zatrazz on Jul 3 2020, 7:55 AM.

Details

Summary

ARM thumb/thumb2 frame pointer is inconsistent on GCC and Clang [1]
and fast-unwider is also unreliable with mixing arm and thumb code [2].

The fast unwinder ARM hacks to probe and compare the frame-pointer
in different stack layout position works reliable only on a system where
all the libraries are built in arm mode (either with gcc or clang).

However when mixing objects built with different abi mode the
fast unwinder is still problematic. The quarantine_size_mb.cpp
still fails on ARM on system with libraries built with thumb (Ubuntu
bionic for instance) so make is pass clean this patch forces it to
use the slow unwinder is to avoid a leak warning triggered by the
helper quarantine thread creation (the allocation is done by glibc
pthread_create). Without proper stack frame information libsanitizer
can not apply the expected suppresion in this case.

This should fix BZ#44158, however the leak sanitizier is still
unreliable on most distros where the system compiler defaults to
use thumb.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92172
[2] https://bugs.llvm.org/show_bug.cgi?id=44158

Diff Detail

Event Timeline

zatrazz created this revision.Jul 3 2020, 7:55 AM

Is unwinding actually broken on an all-clang, all-thumb system?

Is unwinding actually broken on an all-clang, all-thumb system?

The issue is when instrumented objects interact with gcc object,, for instance running instrumented binaries on usual distros like Ubuntu. I haven't tested on a all-clang/all-thumb system, but from my understanding is clang thumb use the FP similar no arm mode (differerent than gcc), so it should work.

Is this patch still needed?

Is this patch still needed?

It is to at least make the unwinder not triggering testcase failures on some arm-linux-gnu distros [1]. The fast-unwinder on ARM does not work correctly when unwinding any thumb code built code by gcc, so it would potentially fail on some scenarios (for instance if system libraries or gcc-build ones call malloc). It should be mitigated by 'fast_unwind_on_check=0' and/or 'fast_unwind_on_malloc=0'.

This issues has come up multiple times and compiler-rt developers either state that Android (which is now built with clang) and clang built objects works and that _Unwind based unwind is too slow to be usable. I think we should at least document this issues with gcc built with thumb support and the possible mitigations and tradeoffs.

[1] http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/11561

eugenis accepted this revision.Aug 24 2020, 9:29 AM

LGTM

This revision is now accepted and ready to land.Aug 24 2020, 9:29 AM
vitalybuka accepted this revision.Aug 24 2020, 6:25 PM
zatrazz abandoned this revision.Oct 7 2020, 5:14 AM