This is a resubmission of r313270. It broke standalone builds of
compiler-rt because we were not correctly generating the llvm-lit
script in the standalone build directory.
The fixes incorporated here attempt to find llvm/utils/llvm-lit
from the source tree returned by llvm-config. If present, it
will generate llvm-lit into the output directory. Regardless,
the user can specify -DLLVM_EXTERNAL_LIT to point to a specific
lit.py on their file system. This supports the use case of
someone installing lit via a package manager. If it cannot find
a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or
invalid, then we print a warning that tests will not be able
to run.
Differential Revision: https://reviews.llvm.org/D37756
llvm-svn: 313407
This was originally broken by r258744 which introduced a weak reference
from ubsan to ubsan_cxx. This reference does not work directly on
Windows because COFF has no direct concept of weak symbols. The fix is
to use /alternatename to create a weak external reference to ubsan_cxx.
Also fix the definition (and the name, so that we drop cached values)
of the cmake flag that controls whether to build ubsan_cxx. Now the
user-controllable flag is always on, and we turn it off internally
depending on whether we support building it.
Differential Revision: https://reviews.llvm.org/D37882
llvm-svn: 313391
We now avoid using absolute symbols on Windows (D37407 and D37408),
so this should work.
Fixes PR32770.
Differential Revision: https://reviews.llvm.org/D37883
llvm-svn: 313379
This patch tackles with two issues:
Output stat st_[a|m|c]time fields were holding wrong values.
st_[a|m|c]time fields should have contained value of seconds and instead
these are filled with st_[a|m|c]time_nsec fields which hold nanoseconds.
Build fails for MIPS64 if SANITIZER_ANDROID. Recently <sys/stat.h> from
bionic introduced st_[a|m|c]time_nsec macros for compatibility with old NDKs
and those clashed with the field names of the <asm/stat.h> kernel_stat
structure.
To fix both issues and make sure sanitizer builds on all platforms, we must
un-define all compatibility macros and access the fields directly when
copying the 'time' fields.
Patch by Miodrag Dinic <miodrag.dinic@imgtec.com>
Differential Revision: https://reviews.llvm.org/D35671
llvm-svn: 313360
This patch is still breaking several multi-stage compiler-rt bots.
I already know what the fix is, but I want to get the bots green
for now and then try re-applying in the morning.
llvm-svn: 313335
It was pointed out that compiler-rt has always defined the symbol, but only
recently added it to the public headers. Meaning that libc++abi can re-declare
it instead of needing this macro.
llvm-svn: 313306
Summary:
Libc++abi attempts to use the newly added `__asan_handle_no_return()` when built under ASAN. Unfortunately older versions of compiler-rt do not provide this symbol, and so libc++abi needs a way to detect if `asan_interface.h` actually provides the function.
This patch adds the macro `SANITIZER_ASAN_INTERFACE_HAS_HANDLE_NO_RETURN` which can be used to detect the availability of the new function.
Reviewers: phosek, kcc, vitalybuka, alekseyshl
Reviewed By: phosek
Subscribers: mclow.lists, cfe-commits
Differential Revision: https://reviews.llvm.org/D37871
llvm-svn: 313303
Summary:
In a few functions (`scudoMemalign` and the like), we would call
`ScudoAllocator::FailureHandler::OnBadRequest` if the parameters didn't check
out. The issue is that if the allocator had not been initialized (eg: if this
is the first heap related function called), we would use variables like
`allocator_may_return_null` and `exitcode` that still had their default value
(as opposed to the one set by the user or the initialization path).
To solve this, we introduce `handleBadRequest` that will call `initThreadMaybe`,
allowing the options to be correctly initialized.
Unfortunately, the tests were passing because `exitcode` was still 0, so the
results looked like success. Change those tests to do what they were supposed
to.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D37853
llvm-svn: 313294
The commit did not fix the failing test and instead exposed an inconsistency
between lsan and (t|m|a)san. I'm reverting the patch as it causes more failures
and the original patch had a '||' instead of '&&', which meant that an N32 build
of test would have be incorrect w.r.t. __HAVE_64B_ATOMICS for glibc.
This reverts commit r313248.
llvm-svn: 313291
This patch simplifies LLVM's lit infrastructure by enforcing an ordering
that a site config is always run before a source-tree config.
A significant amount of the complexity from lit config files arises from
the fact that inside of a source-tree config file, we don't yet know if
the site config has been run. However it is *always* required to run
a site config first, because it passes various variables down through
CMake that the main config depends on. As a result, every config
file has to do a bunch of magic to try to reverse-engineer the location
of the site config file if they detect (heuristically) that the site
config file has not yet been run.
This patch solves the problem by emitting a mapping from source tree
config file to binary tree site config file in llvm-lit.py. Then, during
discovery when we find a config file, we check to see if we have a
target mapping for it, and if so we use that instead.
This mechanism is generic enough that it does not affect external users
of lit. They will just not have a config mapping defined, and everything
will work as normal.
On the other hand, for us it allows us to make many simplifications:
* We are guaranteed that a site config will be executed first
* Inside of a main config, we no longer have to assume that attributes
might not be present and use getattr everywhere.
* We no longer have to pass parameters such as --param llvm_site_config=<path>
on the command line.
* It is future-proof, meaning you don't have to edit llvm-lit.in to add
support for new projects.
* All of the duplicated logic of trying various fallback mechanisms of
finding a site config from the main config are now gone.
One potentially noteworthy thing that was required to implement this
change is that whereas the ninja check targets previously used the first
method to spawn lit, they now use the second. In particular, you can no
longer run lit.py against the source tree while specifying the various
`foo_site_config=<path>` parameters. Instead, you need to run
llvm-lit.py.
Differential Revision: https://reviews.llvm.org/D37756
llvm-svn: 313270
glibc changed the implementation of semaphores for glibc 2.21 requiring
some target specific changes for this compiler-rt test. Modify the test
to cope with MIPS64 and do some future/correctness work by tying the
define for MIPS64 to exactly the define of __HAVE_64B_ATOMICS in glibc.
Contributions from Nitesh Jain.
Reviewers: eugenis
Differential Revision: https://reviews.llvm.org/D37829
llvm-svn: 313248
This was intended to be a generic CMake solution to a problem
shared across several projects. It turns out it doesn't interact
very well certain CMake configurations, and furthermore the
"problem" is actually not a problem, as the problematic code
is never executed to begin with. So this really isn't solving
anything.
llvm-svn: 313191
We're seeing strange issues on the public GreenDragon Darwin bots which
we don't understand. x86_64h tests are still being run on pre-Haswell
bots despite the added checks in test/ubsan_minimal/lit.common.cfg,
which were verified on our internal bots.
I'm unable to ssh into the affected public bot, so for now am trying a
more aggressive check which disables all x86_64h testing for
ubsan-minimal on Darwin.
rdar://problem/34409349
llvm-svn: 313189
Vitaly Buka