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
CMake's find_package(Python3) and find_package(Python2) packages have a PYTHON_EXECUTABLE, Python2_EXECUTABLE, and Python3_EXECUTABLE cmake variables which control which version of python is built against. As far as I can tell, the rest of LLVM honors these variables. This can cause the build process to fail when if the automatically selected version of Python can't run due to modifications of LD_LIBRARY_PATH when using spack. The corresponding Spack issue is https://github.com/spack/spack/issues/19908. The corresponding LLVM issue is 48180
I believe an appropriate fix is to add the variables to the list of PASSTHROUGH_VARIABLES in cmake/Modules/AddCompilerRT.cmake, and this fixed compilation errors for me.
This bug affects distributions like Gentoo and package managers like Spack which allow for combinatorial versioning.
Reviewed By: Meinersbur
Differential Revision: https://reviews.llvm.org/D91536
The original code to keep track of the minimum and maximum indices
of allocated 32-bit primary regions was sketchy at best.
`MinRegionIndex` & `MaxRegionIndex` were shared between all size
classes, and could (theoretically) have been updated concurrently. This
didn't materialize anywhere I could see, but still it's not proper.
This changes those min/max indices by making them class specific rather
than global: classes are locked when growing, so there is no
concurrency there. This also allows to simplify some of the 32-bit
release code, that now doesn't have to go through all the regions to
get the proper min/max. Iterate and unmap will no longer have access to
the global min/max, but they aren't used as much so this is fine.
Differential Revision: https://reviews.llvm.org/D91106
In `GetGlobalSizeFromDescriptor` we use `dladdr` to get info on the the
current address. `dladdr` returns 0 if it failed.
During testing on Linux this returned 0 to indicate failure, and
populated the `info` structure with a NULL pointer which was
dereferenced later.
This patch checks for `dladdr` returning 0, and in that case returns 0
from `GetGlobalSizeFromDescriptor` to indicate failure of identifying
the address.
This occurs when `GetModuleNameAndOffsetForPC` succeeds for some address
not in a dynamically loaded library. One example is when the found
"module" is '[stack]' having come from parsing /proc/self/maps.
Differential Revision: https://reviews.llvm.org/D91344
This unit test code was using malloc without a corresponding free.
When the system malloc is not being overridden by the code under
test, it might an asan/lsan allocator that notices leaks.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D91472
Adds a new option, `handle_winexcept` to try to intercept uncaught
Visual C++ exceptions on Windows. On Linux, such exceptions are handled
implicitly by `std::terminate()` raising `SIBABRT`. This option brings the
Windows behavior in line with Linux.
Unfortunately this exception code is intentionally undocumented, however
has remained stable for the last decade. More information can be found
here: https://devblogs.microsoft.com/oldnewthing/20100730-00/?p=13273
Reviewed By: morehouse, metzman
Differential Revision: https://reviews.llvm.org/D89755
This patch enables building compiler-rt builtins for ARM targets that
only support single-precision floating point instructions (e.g., those
with -mfpu=fpv4-sp-d16).
This fixes PR42838
Differential Revision: https://reviews.llvm.org/D90698
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 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/D91208
It turns out that we can't remove the operator new and delete
interceptors on Android without breaking ABI, so bring them back
as forwards to the malloc and free functions.
Differential Revision: https://reviews.llvm.org/D91219
Adjustment to integer division in int_div_impl.inc to avoid undefined behaviour that can occur as a result of having INT_MIN as one of the parameters.
Reviewed By: sepavloff
Differential Revision: https://reviews.llvm.org/D90218
`populateFreelist` was more complicated that it needed to be. We used
to call to `populateBatches` that would do some internal shuffling and
add pointers one by one to the batches, but ultimately this was not
needed. We can get rid of `populateBatches`, and do processing in
bulk. This doesn't necessarily make things faster as this is not on the
hot path, but it makes the function cleaner.
Additionally clean up a couple of items, like `UNLIKELY`s and setting
`Exhausted` to `false` which can't happen.
Differential Revision: https://reviews.llvm.org/D90700
https://reviews.llvm.org/D90811 is breaking our CI builders because
InitializePlatformCommonFlags is not defined. This just adds an empty definition.
This would've been caught on our upstream buildbot, but it's red at the moment
and most likely won't be sending out alert emails for recent failures.
Differential Revision: https://reviews.llvm.org/D90864
There is no need to memset released pages because they are already
zero. On db845c, before:
BM_stdlib_malloc_free_default/131072 34562 ns 34547 ns 20258 bytes_per_second=3.53345G/s
after:
BM_stdlib_malloc_free_default/131072 29618 ns 29589 ns 23485 bytes_per_second=4.12548G/s
Differential Revision: https://reviews.llvm.org/D90814
The tests do not report the expected leak when issued with use_stack
or use_tls option equal to 0 on arm-linux-gnueabihf (ubuntu 18.04,
glibc 2.27).
This issue is being tracked by https://bugs.llvm.org/show_bug.cgi?id=48052
Reland: a2291a58bf.
New fixes for the breakages reported in D85927 include:
- declare a weak decl for `dl_iterate_phdr`, because it does not exist on older APIs
- Do not enable leak-sanitizer if api_level is less than 29, because of `ld.lld: error: undefined symbol: __aeabi_read_tp` for armv7, API level 16.
- Put back the interceptor for `memalign` but still opt out intercepting `__libc_memalign` and `cfree` because both of these don't exist in Bionic.
Reviewed By: srhines, vitalybuka
Differential Revision: https://reviews.llvm.org/D89251
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
d48f2d7 made destructor of SuspendedThreadsList protected, so we need
an empty subclass to pass to the callback now.
Differential Revision: https://reviews.llvm.org/D90695
This patch adds support for building the compiler-rt profile library on AIX.
Reviewed by: phosek
Differential Revision: https://reviews.llvm.org/D90619
The __isPlatformVersionAtLeast routine is an implementation of `if (@available)` check
that uses the _availability_version_check API on Darwin that's supported on
macOS 10.15, iOS 13, tvOS 13 and watchOS 6.
Differential Revision: https://reviews.llvm.org/D90367
- we have clutter-reducing helpers for relaxed atomics that were barely
used, use them everywhere we can
- clang-format everything with a recent version
Differential Revision: https://reviews.llvm.org/D90649
The initial version of GWP-ASan on Fuchsia doesn't support crash and
signal handlers, so this just adds empty stubs to be able to compile
the project on the platform.
Differential Revision: https://reviews.llvm.org/D90537
The issue was unexpected macro expansion when the bot's test output
directory contained a token matching a build system macro (e.g.
"linux"). Switch to using a hardcoded path, which is invalid but is
sufficient for ensuring that the path is passed down to the runtime.
Differential Revision: https://reviews.llvm.org/D90466
Similar to -fprofile-generate=, add -fmemory-profile= which takes a
directory path. This is passed down to LLVM via a new module flag
metadata. LLVM in turn provides this name to the runtime via the new
__memprof_profile_filename variable.
Additionally, always pass a default filename (in $cwd if a directory
name is not specified vi the = form of the option). This is also
consistent with the behavior of the PGO instrumentation. Since the
memory profiles will generally be fairly large, it doesn't make sense to
dump them to stderr. Also, importantly, the memory profiles will
eventually be dumped in a compact binary format, which is another reason
why it does not make sense to send these to stderr by default.
Change the existing memprof tests to specify log_path=stderr when that
was being relied on.
Depends on D89086.
Differential Revision: https://reviews.llvm.org/D89087
This CL introduces the Fuchsia versions of the existing platform
specific functions.
For Fuchsia, we need to track the VMAR (https://fuchsia.dev/fuchsia-src/reference/kernel_objects/vm_address_region)
of the Guarded Pool mapping, and for this purpose I added some platform
specific data structure that remains empty on POSIX platforms.
`getThreadID` is not super useful for Fuchsia so it's just left as a
stub for now.
While testing the changes in my Fuchsia tree, I realized that
`guarded_pool_allocator_tls.h` should have closed the namespace before
including `GWP_ASAN_PLATFORM_TLS_HEADER`, otherwise drama ensues.
This was tested in g3, upstream LLVM, and Fuchsia (with local changes).
Differential Revision: https://reviews.llvm.org/D90483
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
From a code size perspective it turns out to be better to use a
callee-saved register to pass the shadow base. For non-leaf functions
it avoids the need to reload the shadow base into x9 after each
function call, at the cost of an additional stack slot to save the
caller's x20. But with x9 there is also a stack size cost, either
as a result of copying x9 to a callee-saved register across calls or
by spilling it to stack, so for the non-leaf functions the change to
stack usage is largely neutral.
It is also code size (and stack size) neutral for many leaf functions.
Although they now need to save/restore x20 this can typically be
combined via LDP/STP into the x30 save/restore. In the case where
the function needs callee-saved registers or stack spills we end up
needing, on average, 8 more bytes of stack and 1 more instruction
but given the improvements to other functions this seems like the
right tradeoff.
Unfortunately we cannot change the register for the v1 (non short
granules) check because the runtime assumes that the shadow base
register is stored in x9, so the v1 check still uses x9.
Aside from that there is no change to the ABI because the choice
of shadow base register is a contract between the caller and the
outlined check function, both of which are compiler generated. We do
need to rename the v2 check functions though because the functions
are deduplicated based on their names, not on their contents, and we
need to make sure that when object files from old and new compilers
are linked together we don't end up with a function that uses x9
calling an outlined check that uses x20 or vice versa.
With this change code size of /system/lib64/*.so in an Android build
with HWASan goes from 200066976 bytes to 194085912 bytes, or a 3%
decrease.
Differential Revision: https://reviews.llvm.org/D90422
CallInst::updateProfWeight() creates branch_weights with i64 instead of i32.
To be more consistent everywhere and remove lots of casts from uint64_t
to uint32_t, use i64 for branch_weights.
Reviewed By: davidxl
Differential Revision: https://reviews.llvm.org/D88609
We shouldn't be including the libc++ headers from the source tree directly, since those headers are not configured (i.e. they don't use the __config_site) header like they should, which could mean up to ABI differences
Reviewed By: vitalybuka, phosek, ldionne
Differential Revision: https://reviews.llvm.org/D89915
Mitch expressed a preference to not have `#ifdef`s in platform agnostic
code, this change tries to accomodate this.
I am not attached to the method this CL proposes, so if anyone has a
suggestion, I am open.
We move the platform specific member of the mutex into its own platform
specific class that the main `Mutex` class inherits from. Functions are
implemented in their respective platform specific compilation units.
For Fuchsia, we use the sync APIs, as those are also the ones being
used in Scudo.
Differential Revision: https://reviews.llvm.org/D90351
On aarch64 with kernel 4.12.13 the test sporadically fails with
RSS at start: 1564, after mmap: 103964, after mmap+set label: 308768, \
after fixed map: 206368, after another mmap+set label: 308768, after \
munmap: 206368
release_shadow_space.c.tmp: [...]/release_shadow_space.c:80: int \
main(int, char **): Assertion `after_fixed_mmap <= before + delta' failed.
It seems on some executions the memory is not fully released, even
after munmap. And it also seems that ASLR is hurting it by adding
some fragmentation, by disabling it I could not reproduce the issue
in multiple runs.
I finally see why this test is failing (on now 2 bots). Somehow the path
name is getting messed up, and the "linux" converted to "1". I suspect
there is something in the environment causing the macro expansion in the
test to get messed up:
http://lab.llvm.org:8011/#/builders/112/builds/555/steps/5/logs/FAIL__MemProfiler-x86_64-linux__log_path_test_cpphttp://lab.llvm.org:8011/#/builders/37/builds/275/steps/31/logs/stdio
On the avr bot:
-DPROFILE_NAME_VAR="/home/buildbot/llvm-avr-linux/llvm-avr-linux/stage1/projects/compiler-rt/test/memprof/X86_64LinuxConfig/TestCases/Output/log_path_test.cpp.tmp.log2"
after macros expansions becomes:
/home/buildbot/llvm-avr-1/llvm-avr-1/stage1/projects/compiler-rt/test/memprof/X86_64LinuxConfig/TestCases/Output/log_path_test.cpp.tmp.log2
Similar (s/linux/1/) on the other bot.
Disable it while I investigate
After 81f7b96ed0, I can see that the
reason this test is failing on llvm-avr-linux is that it doesn't think
the directory exists (error comes during file open for write command).
Not sure why since this is the main test Output directory and we created
a different file there earlier in the test from the same file open
invocation. Print directory contents in an attempt to debug.
As implemented, the `InterruptHandler` thread was spinning trying to
`select()` on a null "stdin", wasting a significant amount of CPU for no
benefit. As Fuchsia does not have a native concept of stdin (or POSIX
signals), this commit simply removes this feature entirely.
Reviewed By: aarongreen
Differential Revision: https://reviews.llvm.org/D89266
In a similar fashion to D87420 for Scudo, this CL introduces a way to
get thread local variables via a platform-specific reserved TLS slot,
since Fuchsia doesn't support ELF TLS from the libc itself.
If needing to use this, a platform will have to define
`GWP_ASAN_HAS_PLATFORM_TLS_SLOT` and provide `gwp_asan_platform_tls_slot.h`
which will define a `uint64_t *getPlatformGwpAsanTlsSlot()` function
that will return the TLS word of storage.
I snuck in a couple of cleanup items as well, moving some static
functions to anonymous namespace for consistency.
Differential Revision: https://reviews.llvm.org/D90195
The sanitizer-coverage.cpp test case was always failing for me. It turns
out the reason for this is that I was building with
-DLLVM_INSTALL_BINUTILS_SYMLINKS=ON and sancov.py's grep regex does not
handle llvm-objdump's disassembly format (hex immediates have a leading "0x").
While touching those lines also change them to use raw string literals since
invalid escape sequnces will become an error in future python versions.
Also simplify the code by using subprocess.check_output() instead of Popen().
This also works with python2.
Fixes https://bugs.llvm.org/show_bug.cgi?id=44504
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D89648
Matt Morehouse