Page MenuHomePhabricator

[sanitizer] Disable fast_unwind_on_malloc as default for arm-linux-gnu
ClosedPublic

Authored by zatrazz on Oct 7 2020, 5:14 AM.

Details

Summary

This is an updated version of D83143. Instead of disable fast-unwinder
on arm-linux-gnu, it just disable it as *default* instead. It should fix the
possible false-positive malloc failures when iteracting with thumb build
object by GCC, with the expanse of the slowdown from using the slow
library based unwinder. However users still have the option to use the
fast-unwinder.

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 tries to probe and compare the frame-pointer
in different stack layout position and it works reliable only on a
systems where all the libraries are built in arm mode (either with
gcc or clang) or with clang (which uses the same stack frame pointer
layout in arm and thumb).

However when mixing objects built with different abi mode the
fast unwinder is still problematic as shown by the failures on the
AddressSanitizer.ThreadStackReuseTest. For these failures, the
malloc is called by the loader itself and since it has been built
with a thum enabled gcc, the stack frame is not correctly obtained
and the suppression rule and thus not applied (resulting in a leak
warning).

The check for fast-unwinder-works is also changed: instead of checking
f it is explicit enabled in the compiler flags, it now checks if
compiler defined thumb pre-processore.

This should fix BZ#44158.

[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.Oct 7 2020, 5:14 AM
Herald added subscribers: Restricted Project, kristof.beyls, mgorny. · View Herald TranscriptOct 7 2020, 5:14 AM
zatrazz requested review of this revision.Oct 7 2020, 5:14 AM
eugenis accepted this revision.Oct 7 2020, 11:23 AM

I'm fine with this.

This revision is now accepted and ready to land.Oct 7 2020, 11:23 AM
This revision was landed with ongoing or failed builds.Oct 12 2020, 10:36 AM
This revision was automatically updated to reflect the committed changes.