The macOS name mangling adds another underscore. Therefore, on macOS
the __atomic_* functions are actually ___atomic_* in libcompiler_rt.dylib.
To handle this case, prepend the asm() argument with __USER_LABEL_PREFIX__
in the same way that atomic.c does.
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D92833
On subtargets that have a red zone, we will copy the stack pointer to the base
pointer in the prologue prior to updating the stack pointer. There are no other
updates to the base pointer after that. This suggests that we should be able to
restore the stack pointer from the base pointer rather than loading it from the
back chain or adding the frame size back to either the stack pointer or the
frame pointer.
This came about because functions that call setjmp need to restore the SP from
the FP because the back chain might have been clobbered
(see https://reviews.llvm.org/D92906). However, if the stack is realigned, the
restored SP might be incorrect (which is what caused the failures in the two
ASan test cases).
This patch was tested quite extensivelly both with sanitizer runtimes and
general code.
Differential revision: https://reviews.llvm.org/D93327
Kernel support for MTE has been released in Linux 5.10. This means
that it is a stable API and we no longer need to make the support
conditional on a macro. We do need to provide conditional definitions
of the new macros though in order to avoid a dependency on new
kernel headers.
Differential Revision: https://reviews.llvm.org/D93513
canAllocate() does not take into account the header size so it does
not return the right answer in borderline cases. There was already
code handling this correctly in isTaggedAllocation() so split it out
into a separate function and call it from the test.
Furthermore the test was incorrect when MTE is enabled because MTE
does not pattern fill primary allocations. Fix it.
Differential Revision: https://reviews.llvm.org/D93437
Initially we were avoiding the release of smaller size classes due to
the fact that it was an expensive operation, particularly on 32-bit
platforms. With a lot of batches, and given that there are a lot of
blocks per page, this was a lengthy operation with little results.
There has been some improvements since then to the 32-bit release,
and we still have some criterias preventing us from wasting time
(eg, 9x% free blocks in the class size, etc).
Allowing to release blocks < 128 bytes helps in situations where a lot
of small chunks would not have been reclaimed if not for a forced
reclaiming.
Additionally change some `CHECK` to `DCHECK` and rearrange a bit the
code.
I didn't experience any regressions in my benchmarks.
Differential Revision: https://reviews.llvm.org/D93141
It's possible currently that the sanitizer runtimes when testing grab
the path to the symbolizer through *SAN_SYMBOLIZER_PATH=...
This can be polluted by things like Android's setup script. This patch
forces external_symbolizer_path=$new_build_out_dir/llvm-symbolizer when
%env_tool_options is used.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D93352
...where the name of that variable defined in
compiler-rt/lib/builtins/cpu_model.c is decorated with a leading underscore
Differential Revision: https://reviews.llvm.org/D93390
`;` is the default comment marker, which is also used by powerpc*-*-elf target triples.
`@` is the comment marker of powerpc*-*-darwin but the Darwin support has been deleted for PowerPC (D72063).
`%%` is the statement separator used by aarch64-*-darwin (see AArch64MCAsmInfoDarwin, it uses `;` as the comment marker, which is different from most other targets)
Reviewed By: tambre
Differential Revision: https://reviews.llvm.org/D93378
aa772fc85e (D92530) has landed fixing relocations on Darwin.
3000c19df6 (D93236) has landed working around an assembly parser bug on Darwin.
Previous quick-fix d9697c2e6b (D93198) included in this commit.
Invoking the preprocessor ourselves is fragile and would require us to replicate CMake's handling of definitions, compiler flags, etc for proper compatibility.
In my toolchain builds this notably resulted in a bunch of warnings from unused flags as my CMAKE_C_FLAGS includes CPU-specific optimization options.
Notably this part was already duplicating the logic for VISIBILITY_HIDDEN define.
Instead, symlink the files and set the proper set of defines on each.
This should also be faster as we avoid invoking the compiler multiple times.
Fixes https://llvm.org/PR48494
Differential Revision: https://reviews.llvm.org/D93278
Put .cfi_startproc on a new line to avoid hitting the assembly parser bug in MasmParser::parseDirectiveCFIStartProc().
Reviewed By: tambre
Differential Revision: https://reviews.llvm.org/D93236
Make these arguments named constants in the Config class instead
of being positional arguments to MapAllocatorCache. This makes the
configuration easier to follow.
Eventually we should follow suit with the other classes but this is
a start.
Differential Revision: https://reviews.llvm.org/D93251
We currently do this for SANITIZER_IOS, which includes devices *and* simulators. This change opts out the check for simulators to unify the behavior with macOS, because VM size is really a property of the host OS, and not the simulator.
<rdar://problem/72129387>
Differential Revision: https://reviews.llvm.org/D93140
aa772fc85e (D92530) has landed fixing Apple builds.
Previous quick-fix d9697c2e6b (D93198) included in this commit.
Invoking the preprocessor ourselves is fragile and would require us to replicate CMake's handling of definitions, compiler flags, etc for proper compatibility.
In my toolchain builds this notably resulted in a bunch of warnings from unused flags as my CMAKE_C_FLAGS includes CPU-specific optimization options.
Notably this part was already duplicating the logic for VISIBILITY_HIDDEN define.
Instead, symlink the files and set the proper set of defines on each.
This should also be faster as we avoid invoking the compiler multiple times.
Fixes https://llvm.org/PR48494
Differential Revision: https://reviews.llvm.org/D93211
Invoking the preprocessor ourselves is fragile and would require us to replicate CMake's handling of definitions, compiler flags, etc for proper compatibility.
In my toolchain builds this notably resulted in a bunch of warnings from unused flags as my CMAKE_C_FLAGS includes CPU-specific optimization options.
Notably this part was already duplicating the logic for VISIBILITY_HIDDEN define.
Instead, symlink the files and set the proper set of defines on each.
This should also be faster as we avoid invoking the compiler multiple times.
Fixes https://llvm.org/PR48494
Reviewed By: ilinpv
Differential Revision: https://reviews.llvm.org/D93178
llvm-cov -path-equivalence=/tmp,... is used by some checked-in coverage mapping
files where the original filename is under /tmp. If the test itself produces the
coverage mapping file, there is no need for /tmp.
For coverage_emptylines.cpp: the source filename is under the build directory.
If the build directory is under /tmp, the path mapping will make
llvm-cov fail to find the file.
MSan uses 77 as exit code since it appeared with c5033786ba ("[msan]
MemorySanitizer runtime."). However, Test runners like the one from
Meson use the GNU standard approach where a exit code of 77 signals
that the test should be skipped [1]. As a result Meson's test runner
reports tests as skipped if MSan is enabled and finds issues:
build $ meson test
ninja: Entering directory `/home/user/code/project/build'
ninja: no work to do.
1/1 PROJECT:all / SimpleTest SKIP 0.09s
I could not find any rationale why 77 was initially chosen, and I
found no other clang sanitizer that uses this value as exit
code. Hence I believe it is safe to change this to a safe
default. You can restore the old behavior by setting the environment
variable MSAN_OPTIONS to "exitcode=77", e.g.
export MSAN_OPTIONS="exitcode=77"
1: https://mesonbuild.com/Unit-tests.html#skipped-tests-and-hard-errors
Reviewed By: #sanitizers, eugenis
Differential Revision: https://reviews.llvm.org/D92490
The wrapper clears shadow for addr and addrlen when written to.
Reviewed By: stephan.yichao.zhao
Differential Revision: https://reviews.llvm.org/D93046
There are a few things that I wanted to reorganize for a while:
- the loop that incrementally goes through classes on failure looked
horrible in assembly, mostly because of `LIKELY`/`UNLIKELY` within
the loop. So remove those, we are already in an unlikely scenario
- hooks are not used by default on Android/Fuchsia/etc so mark the
tests for the existence of the weak functions as unlikely
- mark of couple of conditions as likely/unlikely
- in `reallocate`, the old size was computed again while we already
have it in a variable. So just use the one we have.
- remove the bitwise AND trick and use a logical AND, that has one
less test by using a purposeful underflow when `Size` is 0 (I
actually looked at the assembly of the previous code to steal that
trick)
- move the read of the options closer to where they are used, mark them
as `const`
Overall this makes things a tiny bit faster, but cleaner.
Differential Revision: https://reviews.llvm.org/D92689
The wrapper clears shadow for any bytes written to addr or addrlen.
Reviewed By: stephan.yichao.zhao
Differential Revision: https://reviews.llvm.org/D92964
The wrapper clears shadow for optval and optlen when written.
Reviewed By: stephan.yichao.zhao, vitalybuka
Differential Revision: https://reviews.llvm.org/D92961
Normally compilers will allocate space for struct fields even if the
field is an empty struct. Use the [[no_unique_address]] attribute to
suppress that behavior. This attribute that was introduced in C++20,
but compilers that do not support [[no_unique_address]] will ignore
it since it uses C++11 attribute syntax.
Differential Revision: https://reviews.llvm.org/D92966
Quarantines have always been broken when MTE is enabled because the
quarantine batch allocator fails to reset tags that may have been
left behind by a user allocation.
This was only noticed when running the Scudo unit tests with Scudo
as the system allocator because quarantines are turned off by
default on Android and the test binary turns them on by defining
__scudo_default_options, which affects the system allocator as well.
Differential Revision: https://reviews.llvm.org/D92881
Separate the IRG part from the STZG part since we will need to use
the latter on its own for some upcoming changes.
Differential Revision: https://reviews.llvm.org/D92880
*************
* The problem
*************
See motivation examples in compiler-rt/test/dfsan/pair.cpp. The current
DFSan always uses a 16bit shadow value for a variable with any type by
combining all shadow values of all bytes of the variable. So it cannot
distinguish two fields of a struct: each field's shadow value equals the
combined shadow value of all fields. This introduces an overtaint issue.
Consider a parsing function
std::pair<char*, int> get_token(char* p);
where p points to a buffer to parse, the returned pair includes the next
token and the pointer to the position in the buffer after the token.
If the token is tainted, then both the returned pointer and int ar
tainted. If the parser keeps on using get_token for the rest parsing,
all the following outputs are tainted because of the tainted pointer.
The CL is the first change to address the issue.
**************************
* The proposed improvement
**************************
Eventually all fields and indices have their own shadow values in
variables and memory.
For example, variables with type {i1, i3}, [2 x i1], {[2 x i4], i8},
[2 x {i1, i1}] have shadow values with type {i16, i16}, [2 x i16],
{[2 x i16], i16}, [2 x {i16, i16}] correspondingly; variables with
primary type still have shadow values i16.
***************************
* An potential implementation plan
***************************
The idea is to adopt the change incrementially.
1) This CL
Support field-level accuracy at variables/args/ret in TLS mode,
load/store/alloca still use combined shadow values.
After the alloca promotion and SSA construction phases (>=-O1), we
assume alloca and memory operations are reduced. So if struct
variables do not relate to memory, their tracking is accurate at
field level.
2) Support field-level accuracy at alloca
3) Support field-level accuracy at load/store
These two should make O0 and real memory access work.
4) Support vector if necessary.
5) Support Args mode if necessary.
6) Support passing more accurate shadow values via custom functions if
necessary.
***************
* About this CL.
***************
The CL did the following
1) extended TLS arg/ret to work with aggregate types. This is similar
to what MSan does.
2) implemented how to map between an original type/value/zero-const to
its shadow type/value/zero-const.
3) extended (insert|extract)value to use field/index-level progagation.
4) for other instructions, propagation rules are combining inputs by or.
The CL converts between aggragate and primary shadow values at the
cases.
5) Custom function interfaces also need such a conversion because
all existing custom functions use i16. It is unclear whether custome
functions need more accurate shadow propagation yet.
6) Added test cases for aggregate type related cases.
Reviewed-by: morehouse
Differential Revision: https://reviews.llvm.org/D92261
On RH66 does not support 'PTRACE_GETREGSET'. This change makes this part of compiler-rt build again on older os-es
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D91686
The non-pthread functions are all clear discard functions.
Some of the pthread ones could clear shadow, but aren't worth writing
custom wrappers for. I can't think of any reasonable scenario where we
would pass tainted memory to these pthread functions.
Reviewed By: stephan.yichao.zhao
Differential Revision: https://reviews.llvm.org/D92877
On RH66, timespec_get is not available. Use clock_gettime instead.
This problem was introduced with D87120
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D91687
This patch adds both extendhftf2 and trunctfhf2 to support
conversion between half-precision and quad-precision floating-point
values. They are built iff the compiler supports _Float16.
Some notes on ARM plaforms: while fp16 is supported on all
architectures, _Float16 is supported only for 32-bit ARM, 64-bit ARM,
and SPIR (as indicated by clang/docs/LanguageExtensions.rst). Also,
fp16 is a storage format and 64-bit ARM supports floating-point
convert precision to half as base armv8-a instruction.
This patch does not change the ABI for 32-bit ARM, it will continue
to pass _Float16 as uint16.
This re-enabled revert done by https://reviews.llvm.org/rGb534beabeed3ba1777cd0ff9ce552d077e496726
Differential Revision: https://reviews.llvm.org/D92242
This patch is similar to D84708. When testing compiler-rt on different
baremetal targets, it helps to have the ability to pass some more parameters
at test time that allows you to build the test executable for a
given target. For an example, you may need a different linker command
file for different targets.
This patch will allows to do things like
$ llvm-lit --param=append_target_cflags="-T simulator.ld"
or
$ llvm-lit --param=append_target_cflags="-T hardware.ld"
In this way, you can run tests on different targets without having to run
cmake again.
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D91783
Support SX Aurora VE by __clear_cache() function. This modification
allows VE to run written data, e.g. clear_cache_test.c under compiler-rt
test. We still have code alignment problem in enable_execute_stack_test.c,
though.
Reviewed By: simoll
Differential Revision: https://reviews.llvm.org/D92703
r302591 dropped -fsanitize-address-globals-dead-stripping for ELF platforms
(to work around a gold<2.27 bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19002)
Upgrade REQUIRES: from lto (COMPILER_RT_TEST_USE_LLD (set by Android, but rarely used elsewhere)) to lto-available.
If COMPILER_RT_TEST_USE_LLD is not set, config.use_lld will be False.
However, if feature 'binutils_lto' is available, lto_supported can still be True,
but config.target_cflags will not get -fuse-ld=lld from config.lto_flags
As a result, we may use clang -flto with system 'ld' which may not support the bitcode file, e.g.
ld: error: /tmp/lto-constmerge-odr-44a1ee.o: Unknown attribute kind (70) (Producer: 'LLVM12.0.0git' Reader: 'LLVM 12.0.0git')
// The system ld+LLVMgold.so do not support ATTR_KIND_MUSTPROGRESS (70).
Just require lld-available and add -fuse-ld=lld.
This patch fixes builtins' CMakeLists.txt and their VFP tests to check
the standard macro defined in the ACLE for VFP support. It also enables
the tests to be built and run for single-precision-only targets while
builtins were built with double-precision support.
Differential revision: https://reviews.llvm.org/D92497
This is a child diff of D92261.
It extended TLS arg/ret to work with aggregate types.
For a function
t foo(t1 a1, t2 a2, ... tn an)
Its arguments shadow are saved in TLS args like
a1_s, a2_s, ..., an_s
TLS ret simply includes r_s. By calculating the type size of each shadow
value, we can get their offset.
This is similar to what MSan does. See __msan_retval_tls and __msan_param_tls
from llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp.
Note that this change does not add test cases for overflowed TLS
arg/ret because this is hard to test w/o supporting aggregate shdow
types. We will be adding them after supporting that.
Reviewed-by: morehouse
Differential Revision: https://reviews.llvm.org/D92440
On AArch64 it allows use the native FP16 ABI (although libcalls are
not emitted for fptrunc/fpext lowering), while on other architectures
the expected current semantic is preserved (arm for instance).
For testing the _Float16 usage is enabled by architecture base,
currently only for arm, aarch64, and arm64.
This re-enabled revert done by https://reviews.llvm.org/rGb534beabeed3ba1777cd0ff9ce552d077e496726
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D92241
Right now, the regex expression will fail if the flags were not set. Instead, we should follow the pattern of other llvm projects and quote the expression, so that it can work even when the flags are not set.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D92586
Move the two different definitions of FUNC_ALIGN out of the ELF
specific block. Add the missing CFI_END in
END_COMPILERRT_OUTLINE_FUNCTION, to go with the corresponding CFI_START
in DEFINE_COMPILERRT_OUTLINE_FUNCTION_UNMANGLED.
Differential Revision: https://reviews.llvm.org/D92549
In ScopedString::append va_list ArgsCopy is created but never cleanuped
which can lead to undefined behaviour, like stack corruption.
Reviewed By: cryptoad
Differential Revision: https://reviews.llvm.org/D92383
This is consistent with other platforms' versions and
eliminates a compiler warning.
Reviewed By: leonardchan
Differential Revision: https://reviews.llvm.org/D92442
The LateInit test might be reusing some already initialized thread
specific data if run within the main thread. This means that there
is a chance that the current value will not be enough for the 100
iterations, hence the test flaking.
Fix this by making the test run in its own thread.
Differential Revision: https://reviews.llvm.org/D92415
The author of "https://reviews.llvm.org/D92428" marked
'resize_tls_dynamic.cpp' with XFAIL for powerpc64 since
it fails on a bunch of PowerPC buildbots. However, the
original test case passes on clang-ppc64le-rhel bot. So
marking this as XFAIL makes this bot to fail as the test
case passes unexpectedly. We are marking this unsupported
on all PowerPC64 for now until it is fixed for all the
PowerPC buildbots.
The MSVC specific pragmas disable this warning, but the pragmas themselves
(when not guarded by any _MSC_VER ifdef) cause warnings for other targets,
e.g. when targeting mingw.
Instead silence the MSVC warnings about unused parameters by casting
the parameters to void.
Differential Revision: https://reviews.llvm.org/D91851
Previously, ASan would produce reports like this:
ERROR: AddressSanitizer: breakpoint on unknown address 0x000000000000 (pc 0x7fffdd7c5e86 ...)
This is unhelpful, because the developer may think this is a null
pointer dereference, and not a breakpoint exception on some PC.
The cause was that SignalContext::GetAddress would read the
ExceptionInformation array to retreive an address for any kind of
exception. That data is only available for access violation exceptions.
This changes it to be conditional on the exception type, and to use the
PC otherwise.
I added a variety of tests for common exception types:
- int div zero
- breakpoint
- ud2a / illegal instruction
- SSE misalignment
I also tightened up IsMemoryAccess and GetWriteFlag to check the
ExceptionCode rather than looking at ExceptionInformation[1] directly.
Differential Revision: https://reviews.llvm.org/D92344
Revert "[compiler-rt] [builtins] Support conversion between fp16 and fp128" & dependency
Revert "[compiler-rt] [builtins] Use _Float16 on extendhfsf2, truncdfhf2 __truncsfhf2 if available"
This reverts commit 7a94829881.
This reverts commit 1fb91fcf9c.
The include header sys/ucontext.h already defines REG_SP as 2, causing
redefinition warnings during compilation. This patch fixes that issue.
(We also can't just use the numerical definition provided by the header,
as REG_SP is used in this file this refers to a struct field.)
Differential Revision: https://reviews.llvm.org/D90934
Remove an invalid check from sizes.cpp that only passes when overcommit is disabled.
Fixes PR48274.
Differential Revision: https://reviews.llvm.org/D91999
Similar to __asan_set_error_report_callback, pass the entire report to a
user provided callback function.
Differential Revision: https://reviews.llvm.org/D91825
Also unpoison IO_write_base/_IO_write_end buffer
memcpy from fclose and fflash can copy internal bytes without metadata into user memory.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D91858
During the initial Solaris sanitizer port, I missed to enable the
`sanitizer_common` and `ubsan_minimal` testsuites. This patch fixes this,
correcting a few unportabilities:
- `Posix/getpass.cpp` failed to link since Solaris lacks `libutil`.
Omitting the library lets the test `PASS`, but I thought adding `%libutil`
along the lines of `%librt` to be overkill.
- One subtest of `Posix/getpw_getgr.cpp` is disabled because Solaris
`getpwent_r` has a different signature than expected.
- `/dev/null` is a symlink on Solaris.
- XPG7 specifies that `uname` returns a non-negative value on success.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D91606
As reported in PR 48202, two allocator tests `FAIL` on Solaris/sparcv9,
presumably because Solaris uses the full 64-bit address space and the
allocator cannot deal with that:
SanitizerCommon-Unit :: ./Sanitizer-sparcv9-Test/SanitizerCommon.CombinedAllocator32Compact
SanitizerCommon-Unit :: ./Sanitizer-sparcv9-Test/SanitizerCommon.SizeClassAllocator32Iteration
This patch disables the tests.
Tested on `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D91622
Many of the `FastUnwindTest.*` tests `FAIL` on SPARC, both Solaris and
Linux. The issue is that the fake stacks used in those tests don't match
the requirements of the SPARC unwinder in `sanitizer_stacktrace_sparc.cpp`
which has to look at the register window save area.
I'm disabling the failing tests.
Tested on `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D91618
On AArch64 it allows use the native FP16 ABI (although libcalls are
not emitted for fptrunc/fpext lowering), while on other architectures
the expected current semantic is preserved (arm for instance).
Differential Revision: https://reviews.llvm.org/D91733
This patch adds both extendhftf2 and trunctfhf2 to support
conversion between half-precision and quad-precision floating-point
values. They are enabled iff the compiler supports _Float16.
Some notes on ARM plaforms: while __fp16 is supported on all
architectures, _Float16 is supported only for 32-bit ARM, 64-bit ARM,
and SPIR (as indicated by clang/docs/LanguageExtensions.rst). Also,
__fp16 is a storage format and promoted to 'float' for argument passing
and 64-bit ARM supports floating-point convert precision to half as
base armv8-a instruction.
It means that although extendhfsf2, truncdfhf2 __truncsfhf2 will be
built for 64-bit ARM, they will be never used in practice (compiler
won't emit libcall to them). This patch does not change the ABI for
32-bit ARM, it will continue to pass _Float16 as uint16.
Differential Revision: https://reviews.llvm.org/D91732
Add a new interface __sanitizer_get_report_path which will return the
full path to the report file if __sanitizer_set_report_path was
previously called (otherwise it returns null). This is useful in
particular for memory profiling handlers to access the path which
was specified at compile time (and passed down via
__memprof_profile_filename), including the pid added to the path when
the file is opened.
There wasn't a test for __sanitizer_set_report_path, so I added one
which additionally tests the new interface.
Differential Revision: https://reviews.llvm.org/D91765
HwasanThreadList::DontNeedThread clobbers Thread::next_,
Breaking the freelist. As a result, only the top of the freelist ever
gets reused, and the rest of it is lost.
Since the Thread object with its associated ring buffer is only 8Kb, this is
typically only noticable in long running processes, such as fuzzers.
Fix the problem by switching from an intrusive linked list to a vector.
Differential Revision: https://reviews.llvm.org/D91392
Disable the test on old systems.
pthread_cond_clockwait is supported by glibc-2.30.
It also supported by Android api 30 even though we
do not run tsan on Android.
Fixes https://github.com/google/sanitizers/issues/1259
Reviewed By: dvyukov
This modifies the tests so that they can be run on Fuchsia:
- add the necessary includes for `set`/`vector` etc
- do the few modifications required to use zxtest instead og gtest
`backtrace.cpp` requires stacktrace support that Fuchsia doesn't have
yet, and `enable_disable.cpp` currently uses `fork()` which Fuchsia
doesn't support yet. I'll revisit this later.
I chose to use `harness.h` to hold my "platform-specific" include and
namespace, and using this header in tests rather than `gtest.h`,
which I am open to change if someone would rather go another direction.
Differential Revision: https://reviews.llvm.org/D91575
If the containing allocator build uses -DGWP_ASAN_DEFAULT_ENABLED=false
then the option will default to false. For e.g. Scudo, this is simpler
and more efficient than using -DSCUDO_DEFAULT_OPTIONS=... to set gwp-asan
options that have to be parsed from the string at startup.
Reviewed By: hctim
Differential Revision: https://reviews.llvm.org/D91463
Alex Richardson