Commit Graph

356 Commits

Author SHA1 Message Date
Vitaly Buka 234857f730 [sanitizer] Fix -fno-emulated-tls setup
COMPILER_RT_TEST_COMPILER_CFLAGS is a string
2020-11-04 19:23:28 -08:00
Vitaly Buka 09ec07827b [sanitizer] Get Android API from --target
Depends on D90792.

Differential Revision: https://reviews.llvm.org/D90793
2020-11-04 14:05:44 -08:00
Vy Nguyen 6b67e22ea3 Fix breakage in D89615 (due to cmake version 3.16.5)
Differential Revision: https://reviews.llvm.org/D90764
2020-11-04 11:19:01 -05:00
Vy Nguyen aa662f61de Disable emulated-tls for compiler-rt+tests on Android if ELF_TLS is presence.
This is necessary for enabling LSAN on Android (D89251) because:
 - LSAN will have false negatives if run with emulated-tls.
 - Bionic ELF-TLS is not compatible with Gold (hence the need for LLD)

Differential Revision: https://reviews.llvm.org/D89615
2020-11-04 09:49:45 -05:00
Vitaly Buka e86205680e [sanitizer] Remove ANDROID_NDK_VERSION 2020-11-04 01:15:25 -08:00
Vitaly Buka 9c31e12609 [sanitizer] Remove -Wno-non-virtual-dtor
Warning should be fixed with d48f2d7c02
2020-11-04 00:51:33 -08:00
Vy Nguyen 707d69ff32 Use LLD for Android compiler-rt
Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D90720
2020-11-04 00:51:18 -08:00
Petr Hosek 11efd002b1 [CMake] Avoid accidental C++ standard library dependency in sanitizers
While sanitizers don't use C++ standard library, we could still end
up accidentally including or linking it just by the virtue of using
the C++ compiler. Pass -nostdinc++ and -nostdlib++ to avoid these
accidental dependencies.

Reviewed By: smeenai, vitalybuka

Differential Revision: https://reviews.llvm.org/D88922
2020-10-31 02:37:38 -07:00
Petr Hosek d11710dae6 [NFC][CMake] Move some COMPILER_RT variables setup
Part of D88922
2020-10-30 20:09:50 -07:00
Teresa Johnson 3d4bba302d [MemProf] Memory profiling runtime support
See RFC for background:
http://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html

Follow on companion to the clang/llvm instrumentation support in D85948
and committed earlier.

This patch adds the compiler-rt runtime support for the memory
profiling.

Note that much of this support was cloned from asan (and then greatly
simplified and renamed). For example the interactions with the
sanitizer_common allocators, error handling, interception, etc.

The bulk of the memory profiling specific code can be found in the
MemInfoBlock, MemInfoBlockCache, and related classes defined and used
in memprof_allocator.cpp.

For now, the memory profile is dumped to text (stderr by default, but
honors the sanitizer_common log_path flag). It is dumped in either a
default verbose format, or an optional terse format.

This patch also adds a set of tests for the core functionality.

Differential Revision: https://reviews.llvm.org/D87120
2020-10-16 09:47:02 -07:00
Petr Hosek 220de1f32a Revert "[CMake] Avoid accidental C++ standard library dependency in sanitizers"
This reverts commit 287c318690 which broke
sanitizer tests that use C++ standard library.
2020-10-14 18:44:09 -07:00
Petr Hosek 287c318690 [CMake] Avoid accidental C++ standard library dependency in sanitizers
While sanitizers don't use C++ standard library, we could still end
up accidentally including or linking it just by the virtue of using
the C++ compiler. Pass -nostdinc++ and -nostdlib++ to avoid these
accidental dependencies.

Differential Revision: https://reviews.llvm.org/D88922
2020-10-14 18:26:56 -07:00
Adhemerval Zanella 039126c97d [sanitizer] Disable fast_unwind_on_malloc as default for arm-linux-gnu
ARM thumb/thumb2 frame pointer is inconsistent on GCC and Clang [1]
and fast-unwider is also unreliable when mixing arm and thumb code [2].

The fast unwinder on ARM tries to probe and compare the frame-pointer
at different stack layout positions and it works reliable only on
systems where all the libraries were built in arm mode (either with
gcc or clang) or with clang in thmb mode (which uses the same stack
frame pointer layout in arm and thumb).

However when mixing objects built with different abi modes 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 is 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-processor.

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

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D88958
2020-10-12 14:36:08 -03:00
David Tenty 89074bdc81 [AIX][compiler-rt] Use the AR/ranlib mode flag for 32-bit and 64-bit mode
since we will be building both 32-bit and 64-bit compiler-rt builtins
from a single configuration.

Reviewed By: hubert.reinterpretcast

Differential Revision: https://reviews.llvm.org/D87113
2020-09-22 11:10:47 -04:00
Raul Tambre 86bd8f82cc [CMake] Remove dead FindPythonInterp code
LLVM has bumped the minimum required CMake version to 3.13.4, so this has become dead code.

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D87189
2020-09-08 15:23:23 +03:00
Jinsong Ji 0cefaec2e8 [compiler-rt] Don't build llvm-lit in RUNTIMES-BUILD
With runtimes-build, we lost map config for llvm-lit, so we can NOT run
lit from source dir anymore.
All the subdir target like: ninja check-llvm-codegen-powerpc will fail
too.

We will get some cfg error like:
  File "../lvm-project/llvm/test/lit.cfg.py", line 21, in <module>
    config.test_format = lit.formats.ShTest(not llvm_config.use_lit_shell)
AttributeError: 'NoneType' object has no attribute 'use_lit_shell'

This is reset of map config in llvm-lit rebuild.
We already have llvm-lit in runtimes-build, so don't build it.

Reviewed By: phosek

Differential Revision: https://reviews.llvm.org/D87002
2020-09-03 01:08:16 +00:00
Shoaib Meenai 2c80e2fe51 [runtimes] Use llvm-libtool-darwin for runtimes build
It's full featured now and we can use it for the runtimes build instead
of relying on an external libtool, which means the CMAKE_HOST_APPLE
restriction serves no purpose either now. Restrict llvm-lipo to Darwin
targets while I'm here, since it's only needed there.

Reviewed By: phosek

Differential Revision: https://reviews.llvm.org/D86367
2020-08-24 13:48:30 -07:00
Louis Dionne afa1afd410 [CMake] Bump CMake minimum version to 3.13.4
This upgrade should be friction-less because we've already been ensuring
that CMake >= 3.13.4 is used.

This is part of the effort discussed on llvm-dev here:

  http://lists.llvm.org/pipermail/llvm-dev/2020-April/140578.html

Differential Revision: https://reviews.llvm.org/D78648
2020-07-22 14:25:07 -04:00
Petr Hosek cf1d044843 [CMake][compiler-rt] Only set lld as available when it was built
The `-fuse-ld=lld` check might succeed because there's a system lld,
but that lld may be out-of-date which would cause any tests that
attempt to use for LTO fail. This was observed on some of the bots.

Differential Revision: https://reviews.llvm.org/D81629
2020-06-29 15:09:05 -07:00
Saleem Abdulrasool a5d79e5fa1 build: use Python3 for compiler-rt
compiler-rt is built in a unified configuration on some of the builders
which requires that this is updated to follow the same pattern as LLVM.
2020-04-28 17:29:04 +00:00
Nico Weber e613f0ee8d Reland "Make llvm_source_root in llvm-lit relative too."
This reverts commit 3185881d69
and adds a missing "include(AddLLVM)" (similar lines already
exist elsewhere in compiler-rt).
2020-04-06 20:49:10 -04:00
Riyaz V Puthiyapurayil 9657446313 [compiler-rt] Build with correct ABI (PR38025)
Summary:
This patch fixes [[ https://bugs.llvm.org/show_bug.cgi?id=38025 | PR38025 ]]:
Wrong ABI used when building compiler-rt

Differential Revision: https://reviews.llvm.org/D74133
2020-04-03 11:53:40 -07:00
George Burgess IV 20dfcf189d [cmake] By default do not build compiler-rt with PGO
Patch by Zhizhou Yang!

In his own words:

"""
Currently compiler-rt doesn't officially support either PGO
instrumentation or use PGO profdata to build it.

PGO related flags are passed into compiler-rt since rL372209, and
causing bugs: 45022, crbug:1018840

This patch adds several checks in compiler-rt to disable PGO related
flags and provides a flag to turn on PGO for compiler-rt if needed.
"""

Differential Revision: https://reviews.llvm.org/D75499
2020-03-09 15:52:38 -07:00
Hubert Tong e429f24ed8 [CMake] Enable -qfuncsect when building with IBM XL
Summary:
The IBM XL compiler uses `-qfuncsect` for `-ffunction-sections`.

The comment about sanitizers and `-f[no-]function-sections` is corrected
also, as it is pertinent to this patch.

The sanitizer-related use of `-fno-function-sections` is associated with
powerpc64le, a target for which there is an IBM XL compiler, so that use
is updated in this patch to apply `-qnofuncsect` in case a build using
the XL compiler is viable on that platform.

This patch has been verified with the XL compiler on AIX only.

Reviewers: daltenty, stevewan

Reviewed By: daltenty

Subscribers: mgorny, steven.zhang, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D72335
2020-01-15 10:45:50 -05:00
Sterling Augustine 38c356176b Fix include guard and properly order __deregister_frame_info.
Summary:
This patch fixes two problems with the crtbegin.c as written:

1. In do_init, register_frame_info is not guarded by a #define, but in
do_fini, deregister_frame_info is guarded by #ifndef
CRT_HAS_INITFINI_ARRAY. Thus when CRT_HAS_INITFINI_ARRAY is not
defined, frames are registered but then never deregistered.

The frame registry mechanism builds a linked-list from the .so's
static variable do_init.object, and when the .so is unloaded, this
memory becomes invalid and should be deregistered.

Further, libgcc's crtbegin treats the frame registry as independent
from the initfini array mechanism.

This patch fixes this by adding a new #define,
"EH_USE_FRAME_INFO_REGISTRY", which is set by the cmake option
COMPILER_RT_CRT_USE_EH_FRAME_REGISTRY Currently, do_init calls
register_frame_info, and then calls the binary's constructors. This
allows constructors to safely use libunwind. However, do_fini calls
deregister_frame_info and then calls the binary's destructors. This
prevents destructors from safely using libunwind.

This patch also switches that ordering, so that destructors can safely
use libunwind. As it happens, this is a fairly common scenario for
thread sanitizer.
2019-11-12 14:54:41 -08:00
Evgenii Stepanov a1817996fa Fix lld detection in standalone compiler-rt.
Summary:
Right now all hwasan tests on Android are silently disabled because they
require "has_lld" and standalone compiler-rt can not (and AFAIK was
never able to) set it.

Reviewers: pcc

Subscribers: dberris, mgorny, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D69405
2019-10-24 14:46:10 -07:00
Evgenii Stepanov 70316d3174 Revert "Fix lld detection in standalone compiler-rt."
Breaks sanitizer-android buildbot.

This reverts commit d56203201f.
2019-10-22 13:36:06 -07:00
Evgeniy Stepanov d56203201f Fix lld detection in standalone compiler-rt.
Summary:
Right now all hwasan tests on Android are silently disabled because they
require "has_lld" and standalone compiler-rt can not (and AFAIK was
never able to) set it.

Reviewers: pcc, dyung

Subscribers: dberris, mgorny, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D69196

llvm-svn: 375472
2019-10-21 23:59:45 +00:00
Vitaly Buka acd8499028 [compiler-rt] Don't use libcxx if it's not enabled by LLVM_ENABLE_PROJECTS
This fixes sanitizer-x86_64-linux-fuzzer which switched to new layout and not it
can't link as libcxx is always there.
We should support and tests libcxx but still it was unexpected that libfuzzer
ignored LLVM_ENABLE_PROJECTS_USED.

llvm-svn: 370153
2019-08-28 02:41:14 +00:00
Mitch Phillips ae56e593b9 Add GWP-ASan fuzz target to compiler-rt/tools.
Summary:
@eugenis to approve addition of //compiler-rt/tools.
@pree-jackie please confirm that this WFY.

D66494 introduced the GWP-ASan stack_trace_compressor_fuzzer. Building fuzz
targets in compiler-rt is a new affair, and has some challenges:
- If the host compiler doesn't have compiler-rt, the -fsanitize=fuzzer may not
  be able to link against `libclang_rt.fuzzer*`.
- Things in compiler-rt generally aren't built when you want to build with
  sanitizers using `-DLLVM_USE_SANITIZER`. This tricky to work around, so
  we create the new tools directory so that we can build fuzz targets with
  sanitizers. This has the added bonus of fixing the problem above as well, as
  we can now just guard the fuzz target build to only be done with
  `-DLLVM_USE_SANITIZE_COVERAGE=On`.

Reviewers: eugenis, pree-jackie

Reviewed By: eugenis, pree-jackie

Subscribers: dberris, mgorny, #sanitizers, llvm-commits, eugenis, pree-jackie, lebedev.ri, vitalybuka, morehouse

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D66776

llvm-svn: 370094
2019-08-27 18:28:07 +00:00
Ulrich Weigand f7489141be [Sanitizer] Disable -Wframe-larger-than on SystemZ
SystemZ builds show -Wframe-larger-than warnings in two functions:
 'sanitizer::SuspendedThreadsListLinux::GetRegistersAndSP'
 'sanitizer::SizeClassAllocator32<__sanitizer::AP32>::PopulateFreeList'

In both cases, the frame size looks correct; each of the functions has
a large local variable that brings the frame size close to the limit
even on x86, and the extra 160 bytes of the default register save areas
on SystemZ pushes it over the limit.

PowerPC and MIPS already disable this warning; do the same on SystemZ.

Differential Revision: https://reviews.llvm.org/D66021

llvm-svn: 369543
2019-08-21 15:53:08 +00:00
Jonas Devlieghere 4d474e078a [CMake] Check for C++14 instead of C++11
Now that LLVM moved to C++14, `COMPILER_RT_HAS_STD_CXX11_FLAG` should
become `COMPILER_RT_HAS_STD_CXX14_FLAG`.

I ran into this issue when replacing llvm::make_unique with
std::make_unique in an X-ray unit test. We are correctly passing
`-std=c++14`, but this got overwritten further down the invocation by
the compiler-rt flags. Given that this unit test is using LLVM headers,
this is bound to break sooner than later, regardless of my change.

Differential revision: https://reviews.llvm.org/D66271

llvm-svn: 368960
2019-08-15 04:42:15 +00:00
Nico Weber 673dc3d4a0 compiler-rt: Rename cc files below test/asan to cpp
See r367803 and similar other changes.

llvm-svn: 367887
2019-08-05 16:48:12 +00:00
Reid Kleckner c41b58fd40 Remove cmake checks for MSVC 1900 / VS 2013
Our minimum Visual C++ version is 19.10 from Visual Studio 2017.

llvm-svn: 367362
2019-07-30 22:49:11 +00:00
Jonas Devlieghere a5359b1b07 [CMake] Don't set Python_ADDITIONAL_VERSIONS
Until recently, Python_ADDITIONAL_VERSIONS was used to limit LLVM's
Python support to 2.7. Now that both LLVM and LLDB both support Python
3, there's no longer a need to put an arbitrary limit on this.

However, instead of removing the variable, r365692 expanded the list,
which has the (presumably unintentional) side-effect of expression
preference for Python 3.

Instead, as Michal proposed in the original code review, we should just
not set the list at all, and let CMake pick whatever Python interpreter
you have in your path.

This patch removes the Python_ADDITIONAL_VERSIONS variable in llvm,
clang and lld. I've also updated the docs with the default behavior and
how to force a different Python version to be used.

Differential revision: https://reviews.llvm.org/D64894

llvm-svn: 366447
2019-07-18 15:17:42 +00:00
Ulrich Weigand 45b10d2da5 [compiler-rt][SystemZ] Work around ASAN failures via -fno-partial-inlining
Since updating the SystemZ LLVM build bot system to Ubuntu 18.04, all bots
are red due to two ASAN failures.  It turns out these are triggered due to
building the ASAN support libraries, in particular the interceptor routines
using GCC 7.  Specifically, at least on our platform, this compiler decides
to "partially inline" some of those interceptors, creating intermediate
stub routines like "__interceptor_recvfrom.part.321".  These will show up
in the backtraces at interception points, causing testsuite failures.

As a workaround to get the build bots green again, this patch adds the
-fno-partial-inlining command line option when building the common
sanitizer support libraries on s390x, if that option is supported by
the compiler.

llvm-svn: 363679
2019-06-18 13:26:27 +00:00
Petr Hosek d2d6c17760 [builtins] Use libtool for builtins when building for Apple platform
compiler-rt already uses libtool instead of ar when building for
Apple platform, but that's not being used when builtins are being
built separately e.g. as part of the runtimes build. This change
extracts the logic setting up libtool into a separate file and uses
it from both the compiler-rt and standalone builtins build.

Differential Revision: https://reviews.llvm.org/D62820

llvm-svn: 362466
2019-06-04 02:38:15 +00:00
Shoaib Meenai 363079fe73 [compiler-rt] Fix cmake warnings
- Fix cmake BOOL misspellings
 - Set cmake policy for CMP0075 to NEW

As requested by smeenai I've compared CMAkeCache.txt in master with and
without this patch and the only changes are to the variable types I fixed:

     $ diff build-b1-master/CMakeCache.txt build-b1-compiler-rt-fix-cmake-warnings/CMakeCache.txt
     503c503
     < COMPILER_RT_BAREMETAL_BUILD:STRING=OFF
     ---
     > COMPILER_RT_BAREMETAL_BUILD:BOOL=OFF
     550c550
     < COMPILER_RT_HWASAN_WITH_INTERCEPTORS:STRING=ON
     ---
     > COMPILER_RT_HWASAN_WITH_INTERCEPTORS:BOOL=ON

Patch by Wink Saville <wink@saville.com>.

Differential Revision: https://reviews.llvm.org/D61203

llvm-svn: 361866
2019-05-28 19:09:17 +00:00
Julian Lettner e24ed10aac [NFC][TSan][libdispatch] Tiny CMake file cleanup
llvm-svn: 360453
2019-05-10 18:37:30 +00:00
Petr Hosek 999bb5ac27 Reland "[compiler-rt] Simple crtbegin.o and crtend.o implementation"
Clang relies on existence of certain symbols that are normally
provided by crtbegin.o/crtend.o. However, LLVM does not currently
provide implementation of these files, instead relying on either
libgcc or implementations provided as part of the system.

This change provides an initial implementation of crtbegin.o/crtend.o
that can be used on system that don't provide crtbegin.o/crtend.o as
part of their C library.

Differential Revision: https://reviews.llvm.org/D28791

llvm-svn: 359591
2019-04-30 18:13:22 +00:00
Petr Hosek 9300f60c8c Revert "[compiler-rt] Simple crtbegin.o and crtend.o implementation"
This reverts commit r359576 since it's failing on Windows bots.

llvm-svn: 359579
2019-04-30 17:32:05 +00:00
Petr Hosek c8be6e670e [compiler-rt] Simple crtbegin.o and crtend.o implementation
Clang relies on existence of certain symbols that are normally
provided by crtbegin.o/crtend.o. However, LLVM does not currently
provide implementation of these files, instead relying on either
libgcc or implementations provided as part of the system.

This change provides an initial implementation of crtbegin.o/crtend.o
that can be used on system that don't provide crtbegin.o/crtend.o as
part of their C library.

Differential Revision: https://reviews.llvm.org/D28791

llvm-svn: 359576
2019-04-30 17:21:13 +00:00
Julian Lettner f7461b8c5f [TSan][libdispatch] Specify libdispatch header dir for lit tests
Specify libdispatch header dir (include path) for lit tests. This is the
last missing piece in order to run the libdispatch tests on Linux even
when libdispatch is installed in a custom path instead of a default
(system) location.

llvm-svn: 357707
2019-04-04 17:25:43 +00:00
Julian Lettner b8c6effacf [NFC][TSan][libdispatch] Better CMake variable names
llvm-svn: 357664
2019-04-04 01:10:07 +00:00
Julian Lettner 15f0057e66 [TSan][libdispatch] Add Cmake option for libdispatch install path
llvm-svn: 357657
2019-04-04 00:28:09 +00:00
Julian Lettner 9ca4ff2666 [TSan][libdispatch] We don't require any setup on Darwin
llvm-svn: 357519
2019-04-02 20:04:32 +00:00
Julian Lettner 764c2165e8 [TSan][libdispatch] Enable linking and running of tests on Linux
When COMPILER_RT_INTERCEPT_LIBDISPATCH is ON the TSan runtime library
now has a dependency on the blocks runtime and libdispatch. Make sure we
set all the required linking options.

Also add cmake options for specifying additional library paths to
instruct the linker where to search for libdispatch and the blocks
runtime. This allows us to build TSan runtime with libdispatch support
without installing those libraries into default linker library paths.

`CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY` is necessary to avoid
aborting the build due to failing the link step in CMake's
check_c_compiler test.

Reviewed By: dvyukov, kubamracek

Differential Revision: https://reviews.llvm.org/D59334

llvm-svn: 356281
2019-03-15 17:52:27 +00:00
Julian Lettner 98a00defe1 [Sanitizer] Add 'dispatch' feature to be used in compiler-rt tests
Reviewed By: dvyukov

Differential Revision: https://reviews.llvm.org/D59037

llvm-svn: 355617
2019-03-07 18:15:23 +00:00
Julian Lettner 96ef52ccf0 [tsan] Support interception of libdispatch on Linux
This is a new attempt for bringing TSan libdispatch support to Linux.
The main issue with the last patch (https://reviews.llvm.org/D53171) was
that we want to avoid building a separate library.

The updated plan is as follows:
1) Hide libdispatch support behind a flag: true on Darwin, false
   elsewhere. If flag is specified, assume that libdispatch header and
   -flbocks is available for building. This way we can directly include
   the libdispatch header and rely on blocks runtime for our
   implementation.
2) Optionally/weakly intercept libdispatch API functions.

This patch accomplishes 1). It compiles (without the flag enabled) on
Linux. Follow-up patches will provide 2) and enabling of tests on Linux.

Reviewed By: dvyukov

Differential Revision: https://reviews.llvm.org/D58935

llvm-svn: 355538
2019-03-06 19:25:09 +00:00
Martin Storsjo ad596c8d8c [CMake] Don't use llvm_replace_compiler_option
Building compiler-rt standalone outside of the main llvm
tree is supported, and in this case, the llvm cmake modules
are unavailable. (And even if they are available, it requires
including LLVMProcessSources.cmake, which currently isn't
included.)

This fixes building compiler-rt standalone with MSVC/clang-cl.

Differential Revision: https://reviews.llvm.org/D58767

llvm-svn: 355237
2019-03-01 22:30:17 +00:00