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
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
The MemProf compiler-rt support relies on some of the support only built
when COMPILER_RT_BUILD_SANITIZERS was enabled. This showed up in some
initial bot failures, and I addressed those by making the memprof
runtime build also conditional on COMPILER_RT_BUILD_SANITIZERS
(3ed77ecd0a). However, this resulted in
another inconsistency with how the tests were set up that was hit by
Chromium:
https://bugs.chromium.org/p/chromium/issues/detail?id=1142191
Undo the original bot fix and address this with a more comprehensive fix
that enables memprof to be built even when COMPILER_RT_BUILD_SANITIZERS
is disabled, by also building the necessary pieces under
COMPILER_RT_BUILD_MEMPROF.
Tested by configuring with a similar command as to what was used in the
failing Chromium configure. I reproduced the Chromium failure, as well
as the original bot failure I tried to fix in
3ed77ecd0a, with that fix reverted.
Confirmed it now works.
Differential Revision: https://reviews.llvm.org/D90190
In preparation for Fuchsia support, this CL refactors the memory
mapping functions.
The new functions are as follows:
- for Freeslots and Metadata:
`void *map(size_t Size, const char *Name) const;`
`void unmap(void *Ptr, size_t Size) const;`
- for the Pool:
`void *reservePool(size_t Size);`
`void commitPool(void *Ptr, size_t Size) const;`
`void decommitPool(void *Ptr, size_t Size) const;`
`void unreservePool();`
Note that those don't need a `Name` parameter as those are fixed per
function. `{reserve,unreserve}Pool` are not `const` because they will
modify platform specific class member on Fuchsia.
I added a plethora of `assert()` as the initial code was not enforcing
page alignment for sizes and addresses, which caused problem in the
initial Fuchsia draft. All sizes should now be properly rounded up to
a page.
Differential Revision: https://reviews.llvm.org/D89993
Disable the part of this test that started failing only on the
llvm-avr-linux bot after 5c20d7db9f.
Unfortunately, "XFAIL: avr" does not work. Still in the process of
trying to figure out how to debug.
While some platforms call `AsanThread::Init()` from the context of the
thread being started, others (like Fuchsia) call `AsanThread::Init()`
from the context of the thread spawning a child. Since
`AsyncSignalSafeLazyInitFakeStack` writes to a thread-local, we need to
avoid calling it from the spawning thread on Fuchsia. Skipping the call
here on Fuchsia is fine; it'll get called from the new thread lazily on first
attempted access.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D89607
When enabling stack use-after-free detection, we discovered that we read
the thread ID on the main thread while it is still set to 2^24-1.
This patch moves our call to AsanThread::Init() out of CreateAsanThread,
so that we can call SetCurrentThread first on the main thread.
Reviewed By: mcgrathr
Differential Revision: https://reviews.llvm.org/D89606
-print_full_coverage=1 produces a detailed branch coverage dump when run on a single file.
Uses same infrastructure as -print_coverage flag, but prints all branches (regardless of coverage status) in an easy-to-parse format.
Usage: For internal use with machine learning fuzzing models which require detailed coverage information on seed files to generate mutations.
Differential Revision: https://reviews.llvm.org/D85928
Reverts the XFAIL added in b67a2aef8a,
which had no effect.
Adjust the test to make sure all output is dumped to stderr, so that
hopefully I can get a better idea of where/why this is failing.
Remove some redundant checking while here.
While implementing inline stack traces on Windows I noticed that the stack
traces in many asan tests included an inlined frame that shouldn't be there.
Currently we get the PC and then do a stack unwind and use the PC to
find the beginning of the stack trace.
In the failing tests the first thing in the stack trace is inside an inline
call site that shouldn't be in the stack trace, so replace it with the PC.
Differential Revision: https://reviews.llvm.org/D89996
For unknown reasons, this test started failing only on the
llvm-avr-linux bot after 5c20d7db9f2791367b9311130eb44afecb16829c:
http://lab.llvm.org:8011/#/builders/112/builds/365
The error message is not helpful, and I have an email out to the bot
owner to help with debugging. XFAIL it on avr for now.
These compiler-rt tests should be UNSUPPORTED instead of XFAIL, which seems to be the real intent of the authors.
Reviewed By: vvereschaka
Differential Revision: https://reviews.llvm.org/D89840
This is a redo of D89908, which triggered some `-Werror=conversion`
errors with GCC due to assignments to the 31-bit variable.
This CL adds to the original one a 31-bit mask variable that is used
at every assignment to silence the warning.
Differential Revision: https://reviews.llvm.org/D89984
This reverts commit 9903b0586c.
Causes build failures (on GCC 10.2) with the following error:
In file included from /home/nikic/llvm-project/compiler-rt/lib/scudo/standalone/combined.h:29,
from /home/nikic/llvm-project/compiler-rt/lib/scudo/standalone/allocator_config.h:12,
from /home/nikic/llvm-project/compiler-rt/lib/scudo/standalone/wrappers_cpp.cpp:14:
/home/nikic/llvm-project/compiler-rt/lib/scudo/standalone/../../gwp_asan/guarded_pool_allocator.h: In member function ‘bool gwp_asan::GuardedPoolAllocator::shouldSample()’:
/home/nikic/llvm-project/compiler-rt/lib/scudo/standalone/../../gwp_asan/guarded_pool_allocator.h:82:69: error: conversion from ‘uint32_t’ {aka ‘unsigned int’} to ‘unsigned int:31’ may change value [-Werror=conversion]
82 | (getRandomUnsigned32() % (AdjustedSampleRatePlusOne - 1)) + 1;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
We need to have all thread specific data packed into a single `uintptr_t`
for the upcoming Fuchsia support. We can move the `RandomState` into the
`ThreadLocalPackedVariables`, reducing the size of `NextSampleCounter`
to 31 bits (or we could reduce `RandomState` to 31 bits).
We move `getRandomUnsigned32` into the platform agnostic part of the
class, and `initPRNG` in the platform specific part.
`ScopedBoolean` is replaced by actual assignments since non-const
references to bitfields are prohibited.
`random.{h,cpp}` are removed.
Differential Revision: https://reviews.llvm.org/D89908
This will allow the output directory to be specified by a build time
option, similar to the directory specified for regular PGO profiles via
-fprofile-generate=. The memory profiling instrumentation pass will
set up the variable. This is the same mechanism used by the PGO
instrumentation and runtime.
Depends on D87120 and D89629.
Differential Revision: https://reviews.llvm.org/D89086
Split out of D89086 as suggested.
Change the default of the log_path flag to nullptr, and the code
consuming that flag (ReportFile::SetReportPath), to treat nullptr as
stderr (so no change to the behavior of existing users). This allows
code to distinguish between the log_path being specified explicitly as
stderr vs the default.
This is so the flag can be used to override the new report path variable
that will be encoded in the binary for memprof for runtime testing.
Differential Revision: https://reviews.llvm.org/D89629
As discussed in the review for D87120 (specifically at
https://reviews.llvm.org/D87120#inline-831939), clean up PrintModuleMap
and DumpProcessMap usage differences. The former is only implemented for
Mac OSX, whereas the latter is implemented for all OSes. The former is
called by asan and tsan, and the latter by hwasan and now memprof, under
the same option. Simply rename the PrintModuleMap implementation for Mac
to DumpProcessMap, remove other empty PrintModuleMap implementations,
and convert asan/tsan to new name. The existing posix DumpProcessMap is
disabled for SANITIZER_MAC.
Differential Revision: https://reviews.llvm.org/D89630
The RISC-V implementations of the `__mulsi3`, `__muldi3` builtins were
conditionally compiling the actual function definitions depending on whether
the M extension was present or not. This caused Compiler-RT testing failures
for RISC-V targets with the M extension, as when these sources were included
the `librt_has_mul*i3` features were still being defined. These `librt_has_*`
definitions are used to conditionally run the respective tests. Since the
actual functions were not being compiled-in, the generic test for `__muldi3`
would fail. This patch makes these implementations follow the normal
Compiler-RT convention of always including the definition, and conditionally
running the respective tests by using the lit conditional
`REQUIRES: librt_has_*`.
Since the `mulsi3_test.c` wasn't actually RISC-V-specific, this patch also
moves it out of the `riscv` directory. It now only depends on
`librt_has_mulsi3` to run.
Differential Revision: https://reviews.llvm.org/D86457
Few changes wrt utilities:
- split `Check` into a platform agnostic condition test and a platform
specific termination, for which we introduce the function `die`.
- add a platform agnostic `utilities.cpp` that gets the allocation
alignment functions original in the platform specific file, as they
are reusable by all platforms.
Differential Revision: https://reviews.llvm.org/D89811
Do not crash when AsanThread::GetStackVariableShadowStart does not find
a variable for a pointer on a shadow stack.
Differential Revision: https://reviews.llvm.org/D89552
It turned out that at dynamic shared library mode, the memory access
pattern can increase memory footprint significantly on OS when transparent
hugepages (THP) are enabled. This could cause >70x memory overhead than
running a static linked binary. For example, a static binary with RSS
overhead 300M can use > 23G RSS if it is built dynamically.
/proc/../smaps shows in 6204552 kB RSS 6141952 kB relates to
AnonHugePages.
Also such a high RSS happens in some rate: around 25% runs may use > 23G RSS, the
rest uses in between 6-23G. I guess this may relate to how user memory
is allocated and distributted across huge pages.
THP is a trade-off between time and space. We have a flag
no_huge_pages_for_shadow for sanitizer. It is true by default but DFSan
did not follow this. Depending on if a target is built statically or
dynamically, maybe Clang can set no_huge_pages_for_shadow accordingly
after this change. But it still seems fine to follow the default setting of
no_huge_pages_for_shadow. If time is an issue, and users are fine with
high RSS, this flag can be set to false selectively.
This is a follow up patch of https://reviews.llvm.org/D88755.
When set 0 label for an address range, we can release pages within the
corresponding shadow address range to OS, and set only addresses outside
the pages to be 0.
Reviewed-by: morehouse, eugenis
Differential Revision: https://reviews.llvm.org/D89199
Adds some simple sanity checks that the support functions for the atomic
builtins do the right thing. This doesn't test concurrency and memory model
issues.
Differential Revision: https://reviews.llvm.org/D86278
- Fixing VS compiler and other cases settings this time.
Reviewers: dmajor, hans
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D89759
Cleaning up some of the GWP-ASan code base:
- lots of headers didn't have the correct file name
- adding `#ifdef` guard to `utilities.h`
- correcting an `#ifdef` guard based on actual file name
- removing an extra `;`
- clang-format'ing the code (`-style=llvm`)
Differential Revision: https://reviews.llvm.org/D89721
Revert "Fix compiler-rt build on Windows after D89640"
This reverts commit a7acee89d6.
This reverts commit d09b08919c.
Reason: breaks Linux / x86_64 build.
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
Following up D81682 and D83903, remove the code for the old value profiling
buckets, which have been replaced with the new, extended buckets and disabled by
default.
Also syncing InstrProfData.inc between compiler-rt and llvm.
Differential Revision: https://reviews.llvm.org/D88838
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
Summary:
According the mmap man page (https://man7.org/linux/man-pages/man2/mmap.2.html) is only required to precisely control updates, so we can safely remove it.
Since gcda files are dumped just before to call exec** functions, dump need to be fast.
On my computer, Firefox built with --coverage needs ~1min40 to display something and in removing msync it needs ~8s.
Reviewers: void
Subscribers: #sanitizers, marco-c, sylvestre.ledru
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D81060
Currently the 'emulator' value is fixed at build time. This patch allows changing the emulator
at testing time and enables us to run the tests on different board or simulators without needing
to run CMake again to change the value of emulator.
With this patch in place, the value of 'emulator' can be changed at test time from the command
line like this:
$ llvm-lit --param=emulator="..."
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D84708
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
Adds a check to avoid symbolization when printing stack traces if the
stack_trace_format flag does not need it. While there is a symbolize
flag that can be turned off to skip some of the symbolization,
SymbolizePC() still unconditionally looks up the module name and offset.
Avoid invoking SymbolizePC() at all if not needed.
This is an efficiency improvement when dumping all stack traces as part
of the memory profiler in D87120, for large stripped apps where we want
to symbolize as a post pass.
Differential Revision: https://reviews.llvm.org/D88361
After D88686, munmap uses MADV_DONTNEED to ensure zero-out before the
next access. Because the entire shadow space is created by MAP_PRIVATE
and MAP_ANONYMOUS, the first access is also on zero-filled values.
So it is fine to not zero-out data, but use madvise(MADV_DONTNEED) at
mmap. This reduces runtime
overhead.
Reviewed-by: morehouse
Differential Revision: https://reviews.llvm.org/D88755
TSan relies on C++ headers, so when libc++ is being built as part of
the runtimes build, include an explicit dependency on cxx-headers which
is the same approach that's already used for other sanitizers.
Differential Revision: https://reviews.llvm.org/D88912
[11/11] patch series to port ASAN for riscv64
These changes allow using ASAN on RISCV64 architecture.
The majority of existing tests are passing. With few exceptions (see below).
Tests we run on qemu and on "HiFive Unleashed" board.
Tests run:
```
Asan-riscv64-inline-Test - pass
Asan-riscv64-inline-Noinst-Test - pass
Asan-riscv64-calls-Noinst-Test - pass
Asan-riscv64-calls-Test - pass
```
Lit tests:
```
RISCV64LinuxConfig (282 supported, few failures)
RISCV64LinuxDynamicConfig (289 supported, few failures)
```
Lit failures:
```
TestCases/malloc_context_size.cpp - asan works, but backtrace misses some calls
TestCases/Linux/malloc_delete_mismatch.cpp - asan works, but backtrace misses some calls
TestCases/Linux/static_tls.cpp - "Can't guess glibc version" (under debugging)
TestCases/asan_and_llvm_coverage_test.cpp - missing libclang_rt.profile-riscv64.a
```
These failures are under debugging currently and shall be addressed in a
subsequent commits.
Depends On D87581
Reviewed By: eugenis, vitalybuka
Differential Revision: https://reviews.llvm.org/D87582
This moves the platform-specific parameter logic from asan into
lsan_common.h to lsan can share it.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D87795
When an application does a lot of pairs of mmap and munmap, if we did
not release shadoe memory used by mmap addresses, this would increase
memory usage.
Reviewed-by: morehouse
Differential Revision: https://reviews.llvm.org/D88686
It's actually not safe to call TEST_BIG_ENDIAN here, since we may be
running from the builtins build (i.e builtins-config-ix) context where
TEST_COMPILE_ONLY is set since without builtins already built we may
fail to link, and TEST_BIG_ENDIAN internally performs tests which may
fail to link without builtins.
Fortunately powerpc is the only target that uses this information here and
we actually already know the whether we are targeting the LE variant due
to earlier macro checks, so we can simply this to remove our reliance on
TEST_BIG_ENDIAN.
Reviewed By: hubert.reinterpretcast, Whitney
Differential Revision: https://reviews.llvm.org/D88608
[7/11] patch series to port ASAN for riscv64
Depends On D87575
Reviewed By: eugenis, vitalybuka, luismarques
Differential Revision: https://reviews.llvm.org/D87577
`Posix/no_asan_gen_globals.c` currently `FAIL`s on Solaris:
$ nm no_asan_gen_globals.c.tmp.exe | grep ___asan_gen_
0809696a r .L___asan_gen_.1
0809a4cd r .L___asan_gen_.2
080908e2 r .L___asan_gen_.4
0809a4cd r .L___asan_gen_.5
0809a529 r .L___asan_gen_.7
0809a4cd r .L___asan_gen_.8
As detailed in Bug 47607, there are two factors here:
- `clang` plays games by emitting some local labels into the symbol
table. When instead one uses `-fno-integrated-as` to have `gas` create
the object files, they don't land in the objects in the first place.
- Unlike GNU `ld`, the Solaris `ld` doesn't support support
`-X`/`--discard-locals` but instead relies on the assembler to follow its
specification and not emit local labels.
Therefore this patch `XFAIL`s the test on Solaris.
Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D88218
`Posix/unpoison-alternate-stack.cpp` currently `FAIL`s on Solaris/i386.
Some of the problems are generic:
- `clang` warns compiling the testcase:
compiler-rt/test/asan/TestCases/Posix/unpoison-alternate-stack.cpp:83:7: warning: nested designators are a C99 extension [-Wc99-designator]
.sa_sigaction = signalHandler,
^~~~~~~~~~~~~
compiler-rt/test/asan/TestCases/Posix/unpoison-alternate-stack.cpp:84:7: warning: ISO C++ requires field designators to be specified in declaration order; field '_funcptr' will be initialized after field 'sa_flags' [-Wreorder-init-list]
.sa_flags = SA_SIGINFO | SA_NODEFER | SA_ONSTACK,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
and some more instances. This can all easily be avoided by initializing
each field separately.
- The test `SEGV`s in `__asan_memcpy`. The default Solaris/i386 stack size
is only 4 kB, while `__asan_memcpy` tries to allocate either 5436
(32-bit) or 10688 bytes (64-bit) on the stack. This patch avoids this by
requiring at least 16 kB stack size.
- Even without `-fsanitize=address` I get an assertion failure:
Assertion failed: !isOnSignalStack(), file compiler-rt/test/asan/TestCases/Posix/unpoison-alternate-stack.cpp, line 117
The fundamental problem with this testcase is that `longjmp` from a
signal handler is highly unportable; XPG7 strongly warns against it and
it is thus unspecified which stack is used when `longjmp`ing from a
signal handler running on an alternative stack.
So I'm `XFAIL`ing this testcase on Solaris.
Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D88501
Move some of the flags previously in Options, as well as the
UseMemoryTagging flag previously in the primary allocator, into an
atomic variable so that it can be updated while other threads are
running. Relaxed accesses are used because we only have the requirement
that the other threads see the new value eventually.
The code is set up so that the variable is generally loaded once per
allocation function call with the exception of some rarely used code
such as error handlers. The flag bits can generally stay in a register
during the execution of the allocation function which means that they
can be branched on with minimal overhead (e.g. TBZ on aarch64).
Differential Revision: https://reviews.llvm.org/D88523
`TestCases/log-path_test.cpp` currently `FAIL`s on Solaris:
$ env ASAN_OPTIONS=log_path=`for((i=0;i<10000;i++)); do echo -n $i; done` ./log-path_test.cpp.tmp
==5031==ERROR: Path is too long: 01234567...
Segmentation Fault (core dumped)
The `SEGV` happens here:
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x00000000 in ?? ()
(gdb) where
#0 0x00000000 in ?? ()
#1 0x080a1e63 in __interceptor__exit (status=1)
at /vol/gcc/src/llvm/llvm/local/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:3808
#2 0x08135ea8 in __sanitizer::internal__exit (exitcode=1)
at /vol/gcc/src/llvm/llvm/local/projects/compiler-rt/lib/sanitizer_common/sanitizer_solaris.cc:139
when `__interceptor__exit` tries to call `__interception::real__exit` which
is `NULL` at this point because the interceptors haven't been initialized yet.
Ultimately, the problem lies elsewhere, however: `internal__exit` in
`sanitizer_solaris.cpp` calls `_exit` itself since there doesn't exit a
non-intercepted version in `libc`. Using the `syscall` interface instead
isn't usually an option on Solaris because that interface isn't stable.
However, in the case of `SYS_exit` it can be used nonetheless: `SYS_exit`
has remained unchanged since at least Solaris 2.5.1 in 1996, and this is
what this patch does.
Tested on `amd64-pc-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D88404
Said test was flaking on Fuchsia for non-obvious reasons, and only
for ASan variants (the release was returning 0).
It turned out that the templating was off, `true` being promoted to
a `s32` and used as the minimum interval argument. This meant that in
some circumstances, the normal release would occur, and the forced
release would have nothing to release, hence the 0 byte released.
The symbols are giving it away (note the 1):
```
scudo::SizeClassAllocator64<scudo::FixedSizeClassMap<scudo::DefaultSizeClassConfig>,24ul,1,2147483647,false>::releaseToOS(void)
```
This also probably means that there was no MTE version of that test!
Differential Revision: https://reviews.llvm.org/D88457
`atomic_compare_exchange_weak` is unused in Scudo, and its associated
test is actually wrong since the weak variant is allowed to fail
spuriously (thanks Roland).
This lead to flakes such as:
```
[ RUN ] ScudoAtomicTest.AtomicCompareExchangeTest
../../zircon/third_party/scudo/src/tests/atomic_test.cpp:98: Failure: Expected atomic_compare_exchange_weak(reinterpret_cast<T *>(&V), &OldVal, NewVal, memory_order_relaxed) is true.
Expected: true
Which is: 01
Actual : atomic_compare_exchange_weak(reinterpret_cast<T *>(&V), &OldVal, NewVal, memory_order_relaxed)
Which is: 00
../../zircon/third_party/scudo/src/tests/atomic_test.cpp💯 Failure: Expected atomic_compare_exchange_weak( reinterpret_cast<T *>(&V), &OldVal, NewVal, memory_order_relaxed) is false.
Expected: false
Which is: 00
Actual : atomic_compare_exchange_weak( reinterpret_cast<T *>(&V), &OldVal, NewVal, memory_order_relaxed)
Which is: 01
../../zircon/third_party/scudo/src/tests/atomic_test.cpp:101: Failure: Expected OldVal == NewVal.
Expected: NewVal
Which is: 24
Actual : OldVal
Which is: 42
[ FAILED ] ScudoAtomicTest.AtomicCompareExchangeTest (0 ms)
[----------] 2 tests from ScudoAtomicTest (1 ms total)
```
So I am removing this, if someone ever needs the weak variant, feel
free to add it back with a test that is not as terrible. This test was
initially ported from sanitizer_common, but their weak version calls
the strong version, so it works for them.
Differential Revision: https://reviews.llvm.org/D88443
Move smaller and frequently-accessed fields near the beginning
of the data structure in order to improve locality and reduce
the number of instructions required to form an access to those
fields. With this change I measured a ~5% performance improvement on
BM_malloc_sql_trace_default on aarch64 Android devices (Pixel 4 and
DragonBoard 845c).
Differential Revision: https://reviews.llvm.org/D88350
This commit adds an interceptor for the pthread_detach function,
calling into ThreadRegistry::DetachThread, allowing for thread contexts
to be reused.
Without this change, programs may fail when they create more than 8K
threads.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=47389
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D88184
Add support for expanding the %t filename specifier in LLVM_PROFILE_FILE
to the TMPDIR environment variable. This is supported on all platforms.
On Darwin, TMPDIR is used to specify a temporary application-specific
scratch directory. When testing apps on remote devices, it can be
challenging for the host device to determine the correct TMPDIR, so it's
helpful to have the runtime do this work.
rdar://68524185
Differential Revision: https://reviews.llvm.org/D87332
`TestCases/malloc-no-intercept.c` `FAIL`s on Solaris/x86, e.g. with
`-Dtestfunc=mallinfo`:
/usr/bin/ld: /tmp/malloc-no-intercept-586529.o: in function `main':
/vol/llvm/src/llvm-project/dist/compiler-rt/test/asan/TestCases/malloc-no-intercept.c:30: undefined reference to `nonexistent_function'
clang-12: error: linker command failed with exit code 1 (use -v to see invocation)
This is not surprising, actually:
- `mallinfo` and `mallopt` only exist in `libmalloc`
- `pvalloc` doesn't exist all all
- `cfree` does exist in `libc`, but isn't declared in any public header and
the OpenSolaris sources reveal that it has a different signature than on
Linux
- only `memalign` is a public interface
To avoid this, this patch disables the interceptors for all but `meminfo`.
Additionally, the test is marked `UNSUPPORTED` on Solaris since the
`memalign` and `cfree` variants **do** link on Solaris.
Tested on `amd64-pc-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D87898
This reverts commit 0caad9fe44.
This reverts commit c96d0cceb6.
Causes linker errors which were not fixed by the subsequent commit
either:
/home/nikic/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:503: error: undefined reference to '__asan::InstallAtExitCheckLeaks()'
Fix a potential UB in `appendSignedDecimal` (with -INT64_MIN) by making
it a special case.
Fix the terrible test cases for `isOwned`: I was pretty sloppy on those
and used some stack & static variables, but since `isOwned` accesses
memory prior to the pointer to check for the validity of the Scudo
header, it ended up being detected as some global and stack buffer out
of bounds accesses. So not I am using buffers with enough room so that
the test will not access memory prior to the variables.
With those fixes, the tests pass on the ASan+UBSan Fuchsia build.
Thanks to Roland for pointing those out!
Differential Revision: https://reviews.llvm.org/D88170
The `if (0)` isn't necessarily optimized out so as not to create
a link-time reference to LSan runtime functions that might not
exist. So use explicit conditional compilation instead.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D88173
Fuchsia's system libraries are instrumented and use the lsan
allocator for internal purposes. So leak checking needs to run
after all atexit hooks and after the system libraries' internal
exit-time hooks. The <zircon/sanitizer.h> hook API calls the
__sanitizer_process_exit_hook function at exactly the right time.
Reviewed By: vitalybuka, phosek
Differential Revision: https://reviews.llvm.org/D86171
implements glibc-like wrappers over Linux syscalls.
[3/11] patch series to port ASAN for riscv64
Depends On D87998
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D87572
Commit https://reviews.llvm.org/rG144e57fc9535 added this test
case that creates message queues but does not remove them. The
message queues subsequently build up on the machine until the
system wide limit is reached. This has caused failures for a
number of bots running on a couple of big PPC machines.
This patch just adds the missing cleanup.
This patch enables support for building compiler-rt builtins for 32-bit
Power arch on AIX. For now, we leave out the specialized ppc builtin
implementations for 128-bit long double and friends since those will
need some special handling for AIX.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D87383
https://reviews.llvm.org/D87420 removed the uses of the pthread key,
but the key itself was left in the shared TSD registry. It is created
on registry initialization, and destroyed on registry teardown.
There is really no use for it now, so we can just remove it.
Differential Revision: https://reviews.llvm.org/D88046
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
The code currently uses __c11_atomic_is_lock_free() to detect whether an
atomic operation is natively supported. However, this can result in a
runtime function call to determine whether the given operation is lock-free
and clang generating a call to e.g. __atomic_load_8 since the branch is
not a constant zero. Since we are implementing those runtime functions, we
must avoid those calls. This patch replaces __c11_atomic_is_lock_free()
with __atomic_always_lock_free() which always results in a compile-time
constant value. This problem was found while compiling atomic.c for MIPS32
since the -Watomic-alignment warning was being triggered and objdump showed
an undefined reference to _atomic_is_lock_free.
In addition to fixing 32-bit platforms this also enables the 16-byte case
that was disabled in r153779 (185f2edd70).
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D86510
1U has type unsigned int, and << of 32 or more is undefined behavior.
Use the proper type in the lhs of the shift.
Reviewed By: cryptoad
Differential Revision: https://reviews.llvm.org/D87973
Can be used to disable interceptor to workaround issues of
non-instrumented code.
Reviewed By: morehouse, eugenis
Differential Revision: https://reviews.llvm.org/D87897
Here "memory initialization" refers to zero- or pattern-init on
non-MTE hardware, or (where possible to avoid) memory tagging on MTE
hardware. With shared TSD the per-thread memory initialization state
is stored in bit 0 of the TLS slot, similar to PointerIntPair in LLVM.
Differential Revision: https://reviews.llvm.org/D87739
Split out of D87120 (memory profiler). Added unit testing of the new
printing facility.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D87792
The test started to consistently fail after unrelated
2ffaa9a173.
Even before the patch it was possible to fail the test,
e.g. -seed=1660180256 on my workstation.
Also this checks do not look related to strcmp.
X86 can use xmm registers for pointers operations. e.g. for std::swap.
I don't know yet if it's possible on other platforms.
NT_X86_XSTATE includes all registers from NT_FPREGSET so
the latter used only if the former is not available. I am not sure how
reasonable to expect that but LLD has such fallback in
NativeRegisterContextLinux_x86_64::ReadFPR.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D87754
Avoid fallbacking to software emulated compiler atomics, that are usually
provided by libatomic, which is not always present.
This fixes the test on NetBSD, which does not provide libatomic in base.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D87568
On Solaris/x86, several hundred 32-bit tests `FAIL`, all in the same way:
env ASAN_OPTIONS=halt_on_error=false ./halt_on_error_suppress_equal_pcs.cpp.tmp
Segmentation Fault (core dumped)
They segfault during startup:
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x080f21f0 in __sanitizer::internal_mmap(void*, unsigned long, int, int, int, unsigned long long) () at /vol/llvm/src/llvm-project/dist/compiler-rt/lib/sanitizer_common/sanitizer_solaris.cpp:65
65 int prot, int flags, int fd, OFF_T offset) {
1: x/i $pc
=> 0x80f21f0 <_ZN11__sanitizer13internal_mmapEPvmiiiy+16>: movaps 0x30(%esp),%xmm0
(gdb) p/x $esp
$3 = 0xfeffd488
The problem is that `movaps` expects 16-byte alignment, while 32-bit Solaris/x86
only guarantees 4-byte alignment following the i386 psABI.
This patch updates `X86Subtarget::initSubtargetFeatures` accordingly,
handles Solaris/x86 in the corresponding testcase, and allows for some
variation in address alignment in
`compiler-rt/test/ubsan/TestCases/TypeCheck/vptr.cpp`.
Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D87615
Remove RegisterCount and let GetRegistersAndSP to resize buffer as needed.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D87747
This moves the platform-specific parameter logic from asan into
sanitizer_common so lsan can reuse it.
Patch By: mcgrathr
Differential Revision: https://reviews.llvm.org/D85930
When using a custom mutator (e.g. thrift mutator, similar to LPM)
that calls back into libfuzzer's mutations via `LLVMFuzzerMutate`, the mutation
sequences needed to achieve new coverage can get prohibitively large.
Printing these large sequences has two downsides:
1) It makes the logs hard to understand for a human.
2) The performance cost slows down fuzzing.
In this patch I change the `PrintMutationSequence` function to take a max
number of entries, to achieve this goal. I also update `PrintStatusForNewUnit`
to default to printing only 10 entries, in the default verbosity level (1),
requiring the user to set verbosity to 2 if they want the full mutation
sequence.
For our use case, turning off verbosity is not an option, as that would also
disable `PrintStats()` which is very useful for infrastructure that analyzes
the logs in realtime. I imagine most users of libfuzzer always want those logs
in the default.
I built a fuzzer locally with this patch applied to libfuzzer.
When running with the default verbosity, I see logs like this:
#65 NEW cov: 4799 ft: 10443 corp: 41/1447Kb lim: 64000 exec/s: 1 rss: 575Mb L: 28658/62542 MS: 196 Custom-CrossOver-ChangeBit-EraseBytes-ChangeBit-ChangeBit-ChangeBit-CrossOver-ChangeBit-CrossOver- DE: "\xff\xff\xff\x0e"-"\xfe\xff\xff\x7f"-"\xfe\xff\xff\x7f"-"\x17\x00\x00\x00\x00\x00\x00\x00"-"\x00\x00\x00\xf9"-"\xff\xff\xff\xff"-"\xfa\xff\xff\xff"-"\xf7\xff\xff\xff"-"@\xff\xff\xff\xff\xff\xff\xff"-"E\x00"-
#67 NEW cov: 4810 ft: 10462 corp: 42/1486Kb lim: 64000 exec/s: 1 rss: 577Mb L: 39823/62542 MS: 135 Custom-CopyPart-ShuffleBytes-ShuffleBytes-ChangeBit-ChangeBinInt-EraseBytes-ChangeBit-ChangeBinInt-ChangeBit- DE: "\x01\x00\x00\x00\x00\x00\x01\xf1"-"\x00\x00\x00\x07"-"\x00\x0d"-"\xfd\xff\xff\xff"-"\xfe\xff\xff\xf4"-"\xe3\xff\xff\xff"-"\xff\xff\xff\xf1"-"\xea\xff\xff\xff"-"\x00\x00\x00\xfd"-"\x01\x00\x00\x05"-
Staring hard at the logs it's clear that the cap of 10 is applied.
When running with verbosity level 2, the logs look like the below:
#66 NEW cov: 4700 ft: 10188 corp: 37/1186Kb lim: 64000 exec/s: 2 rss: 509Mb L: 47616/61231 MS: 520 Custom-CopyPart-ChangeBinInt-ChangeBit-ChangeByte-EraseBytes-PersAutoDict-CopyPart-ShuffleBytes-ChangeBit-ShuffleBytes-CopyPart-EraseBytes-CopyPart-ChangeBinInt-CopyPart-ChangeByte-ShuffleBytes-ChangeBinInt-ShuffleBytes-ChangeBit-CMP-ShuffleBytes-ChangeBit-CrossOver-ChangeBinInt-ChangeByte-ShuffleBytes-CrossOver-EraseBytes-ChangeBinInt-InsertRepeatedBytes-PersAutoDict-InsertRepeatedBytes-InsertRepeatedBytes-CrossOver-ChangeByte-ShuffleBytes-CopyPart-ShuffleBytes-CopyPart-CrossOver-ChangeBit-ShuffleBytes-CrossOver-PersAutoDict-ChangeByte-ChangeBit-ShuffleBytes-CrossOver-ChangeByte-EraseBytes-CopyPart-ChangeBinInt-PersAutoDict-CrossOver-ShuffleBytes-CrossOver-CrossOver-EraseBytes-CrossOver-EraseBytes-CrossOver-ChangeBit-ChangeBinInt-ChangeByte-EraseBytes-ShuffleBytes-ShuffleBytes-ChangeBit-EraseBytes-ChangeBinInt-ChangeBit-ChangeBinInt-CopyPart-EraseBytes-PersAutoDict-EraseBytes-CopyPart-ChangeBinInt-ChangeByte-CrossOver-ChangeBinInt-ShuffleBytes-PersAutoDict-PersAutoDict-ChangeBinInt-CopyPart-ChangeBinInt-CrossOver-ChangeBit-ChangeBinInt-CopyPart-ChangeByte-ChangeBit-CopyPart-CrossOver-ChangeByte-ChangeBit-ChangeByte-ShuffleBytes-CMP-ChangeBit-CopyPart-ChangeBit-ChangeByte-ChangeBinInt-PersAutoDict-ChangeBinInt-CrossOver-ChangeBinInt-ChangeBit-ChangeBinInt-ChangeBinInt-PersAutoDict-ChangeBinInt-ChangeBinInt-ChangeByte-CopyPart-ShuffleBytes-ChangeByte-ChangeBit-ChangeByte-ChangeByte-EraseBytes-CrossOver-ChangeByte-ChangeByte-EraseBytes-EraseBytes-InsertRepeatedBytes-ShuffleBytes-CopyPart-CopyPart-ChangeBit-ShuffleBytes-PersAutoDict-ShuffleBytes-ChangeBit-ChangeByte-ChangeBit-ShuffleBytes-ChangeByte-ChangeBinInt-CrossOver-ChangeBinInt-ChangeBit-EraseBytes-CopyPart-ChangeByte-CrossOver-EraseBytes-CrossOver-ChangeByte-ShuffleBytes-ChangeByte-ChangeBinInt-CrossOver-ChangeByte-InsertRepeatedBytes-InsertByte-ShuffleBytes-PersAutoDict-ChangeBit-ChangeByte-ChangeBit-ShuffleBytes-ShuffleBytes-CopyPart-ShuffleBytes-EraseBytes-ShuffleBytes-ShuffleBytes-CrossOver-ChangeBinInt-CopyPart-CopyPart-CopyPart-EraseBytes-EraseBytes-ChangeByte-ChangeBinInt-ShuffleBytes-CMP-InsertByte-EraseBytes-ShuffleBytes-CopyPart-ChangeBit-CrossOver-CopyPart-CopyPart-ShuffleBytes-ChangeByte-ChangeByte-ChangeBinInt-EraseBytes-ChangeByte-ChangeBinInt-ChangeBit-ChangeBit-ChangeByte-ShuffleBytes-PersAutoDict-PersAutoDict-CMP-ChangeBit-ShuffleBytes-PersAutoDict-ChangeBinInt-EraseBytes-EraseBytes-ShuffleBytes-ChangeByte-ShuffleBytes-ChangeBit-EraseBytes-CMP-ShuffleBytes-ChangeByte-ChangeBinInt-EraseBytes-ChangeBinInt-ChangeByte-EraseBytes-ChangeByte-CrossOver-ShuffleBytes-EraseBytes-EraseBytes-ShuffleBytes-ChangeBit-EraseBytes-CopyPart-ShuffleBytes-ShuffleBytes-CrossOver-CopyPart-ChangeBinInt-ShuffleBytes-CrossOver-InsertByte-InsertByte-ChangeBinInt-ChangeBinInt-CopyPart-EraseBytes-ShuffleBytes-ChangeBit-ChangeBit-EraseBytes-ChangeByte-ChangeByte-ChangeBinInt-CrossOver-ChangeBinInt-ChangeBinInt-ShuffleBytes-ShuffleBytes-ChangeByte-ChangeByte-ChangeBinInt-ShuffleBytes-CrossOver-EraseBytes-CopyPart-CopyPart-CopyPart-ChangeBit-ShuffleBytes-ChangeByte-EraseBytes-ChangeByte-InsertRepeatedBytes-InsertByte-InsertRepeatedBytes-PersAutoDict-EraseBytes-ShuffleBytes-ChangeByte-ShuffleBytes-ChangeBinInt-ShuffleBytes-ChangeBinInt-ChangeBit-CrossOver-CrossOver-ShuffleBytes-CrossOver-CopyPart-CrossOver-CrossOver-CopyPart-ChangeByte-ChangeByte-CrossOver-ChangeBit-ChangeBinInt-EraseBytes-ShuffleBytes-EraseBytes-CMP-PersAutoDict-PersAutoDict-InsertByte-ChangeBit-ChangeByte-CopyPart-CrossOver-ChangeByte-ChangeBit-ChangeByte-CopyPart-ChangeBinInt-EraseBytes-CrossOver-ChangeBit-CrossOver-PersAutoDict-CrossOver-ChangeByte-CrossOver-ChangeByte-ChangeByte-CrossOver-ShuffleBytes-CopyPart-CopyPart-ShuffleBytes-ChangeByte-ChangeByte-ChangeBinInt-ChangeBinInt-ChangeBinInt-ChangeBinInt-ShuffleBytes-CrossOver-ChangeBinInt-ShuffleBytes-ChangeBit-PersAutoDict-ChangeBinInt-ShuffleBytes-ChangeBinInt-ChangeByte-CrossOver-ChangeBit-CopyPart-ChangeBit-ChangeBit-CopyPart-ChangeByte-PersAutoDict-ChangeBit-ShuffleBytes-ChangeByte-ChangeBit-CrossOver-ChangeByte-CrossOver-ChangeByte-CrossOver-ChangeBit-ChangeByte-ChangeBinInt-PersAutoDict-CopyPart-ChangeBinInt-ChangeBit-CrossOver-ChangeBit-PersAutoDict-ShuffleBytes-EraseBytes-CrossOver-ChangeByte-ChangeBinInt-ShuffleBytes-ChangeBinInt-InsertRepeatedBytes-PersAutoDict-CrossOver-ChangeByte-Custom-PersAutoDict-CopyPart-CopyPart-ChangeBinInt-ShuffleBytes-ChangeBinInt-ChangeBit-ShuffleBytes-CrossOver-CMP-ChangeByte-CopyPart-ShuffleBytes-CopyPart-CopyPart-CrossOver-CrossOver-CrossOver-ShuffleBytes-ChangeByte-ChangeBinInt-ChangeBit-ChangeBit-ChangeBit-ChangeByte-EraseBytes-ChangeByte-ChangeBit-ChangeByte-ChangeByte-CopyPart-PersAutoDict-ChangeBinInt-PersAutoDict-PersAutoDict-PersAutoDict-CopyPart-CopyPart-CrossOver-ChangeByte-ChangeBinInt-ShuffleBytes-ChangeBit-CopyPart-EraseBytes-CopyPart-CopyPart-CrossOver-ChangeByte-EraseBytes-ShuffleBytes-ChangeByte-CopyPart-EraseBytes-CopyPart-CrossOver-ChangeBinInt-ChangeBinInt-InsertByte-ChangeBinInt-ChangeBit-ChangeByte-CopyPart-ChangeByte-EraseBytes-ChangeByte-ChangeBit-ChangeByte-ShuffleBytes-CopyPart-ChangeBinInt-EraseBytes-CrossOver-ChangeBit-ChangeBit-CrossOver-EraseBytes-ChangeBinInt-CopyPart-CopyPart-ChangeBinInt-ChangeBit-EraseBytes-InsertRepeatedBytes-EraseBytes-ChangeBit-CrossOver-CrossOver-EraseBytes-EraseBytes-ChangeByte-CopyPart-CopyPart-ShuffleBytes-ChangeByte-ChangeBit-ChangeByte-EraseBytes-ChangeBit-ChangeByte-ChangeByte-CrossOver-CopyPart-EraseBytes-ChangeByte-EraseBytes-ChangeByte-ShuffleBytes-ShuffleBytes-ChangeByte-CopyPart-ChangeByte-ChangeByte-ChangeBit-CopyPart-ChangeBit-ChangeBinInt-CopyPart-ShuffleBytes-ChangeBit-ChangeBinInt-ChangeBit-EraseBytes-CMP-CrossOver-CopyPart-ChangeBinInt-CrossOver-CrossOver-CopyPart-CrossOver-CrossOver-InsertByte-InsertByte-CopyPart-Custom- DE: "warn"-"\x00\x00\x00\x80"-"\xfe\xff\xff\xfb"-"\xff\xff"-"\x10\x00\x00\x00"-"\xfe\xff\xff\xff"-"\xff\xff\xff\xf6"-"U\x01\x00\x00\x00\x00\x00\x00"-"\xd9\xff\xff\xff"-"\xfe\xff\xff\xea"-"\xf0\xff\xff\xff"-"\xfc\xff\xff\xff"-"warn"-"\xff\xff\xff\xff"-"\xfe\xff\xff\xfb"-"\x00\x00\x00\x80"-"\xfe\xff\xff\xf1"-"\xfe\xff\xff\xea"-"\x00\x00\x00\x00\x00\x00\x012"-"\xe2\x00"-"\xfb\xff\xff\xff"-"\x00\x00\x00\x00"-"\xe9\xff\xff\xff"-"\xff\xff"-"\x00\x00\x00\x80"-"\x01\x00\x04\xc9"-"\xf0\xff\xff\xff"-"\xf9\xff\xff\xff"-"\xff\xff\xff\xff\xff\xff\xff\x12"-"\xe2\x00"-"\xfe\xff\xff\xff"-"\xfe\xff\xff\xea"-"\xff\xff\xff\xff"-"\xf4\xff\xff\xff"-"\xe9\xff\xff\xff"-"\xf1\xff\xff\xff"-
#48 NEW cov: 4502 ft: 9151 corp: 27/750Kb lim: 64000 exec/s: 2 rss: 458Mb L: 50772/50772 MS: 259 ChangeByte-ShuffleBytes-ChangeBinInt-ChangeByte-ChangeByte-ChangeByte-ChangeByte-ChangeBit-CopyPart-CrossOver-CopyPart-ChangeByte-CrossOver-CopyPart-ChangeBit-ChangeByte-EraseBytes-ChangeByte-CopyPart-CopyPart-CopyPart-ChangeBit-EraseBytes-ChangeBinInt-CrossOver-CopyPart-CrossOver-CopyPart-ChangeBit-ChangeByte-ChangeBit-InsertByte-CrossOver-InsertRepeatedBytes-InsertRepeatedBytes-InsertRepeatedBytes-ChangeBinInt-EraseBytes-InsertRepeatedBytes-InsertByte-ChangeBit-ShuffleBytes-ChangeBit-ChangeBit-CopyPart-ChangeBit-ChangeByte-CrossOver-ChangeBinInt-ChangeByte-CrossOver-CMP-ChangeByte-CrossOver-ChangeByte-ShuffleBytes-ShuffleBytes-ChangeByte-ChangeBinInt-CopyPart-EraseBytes-CrossOver-ChangeBit-ChangeBinInt-InsertByte-ChangeBit-CopyPart-ChangeBinInt-ChangeByte-CrossOver-ChangeBit-EraseBytes-CopyPart-ChangeBinInt-ChangeBit-ChangeBit-ChangeByte-CopyPart-ChangeBinInt-CrossOver-PersAutoDict-ChangeByte-ChangeBit-ChangeByte-ChangeBinInt-ChangeBinInt-EraseBytes-CopyPart-CopyPart-ChangeByte-ChangeByte-EraseBytes-PersAutoDict-CopyPart-ChangeByte-ChangeByte-EraseBytes-CrossOver-CopyPart-CopyPart-CopyPart-ChangeByte-ChangeBit-CMP-CopyPart-ChangeBinInt-ChangeBinInt-CrossOver-ChangeBit-ChangeBit-EraseBytes-ChangeByte-ShuffleBytes-ChangeBit-ChangeBinInt-CMP-InsertRepeatedBytes-CopyPart-Custom-ChangeByte-CrossOver-EraseBytes-ChangeBit-CopyPart-CrossOver-CMP-ShuffleBytes-EraseBytes-CrossOver-PersAutoDict-ChangeByte-CrossOver-CopyPart-CrossOver-CrossOver-ShuffleBytes-ChangeBinInt-CrossOver-ChangeBinInt-ShuffleBytes-PersAutoDict-ChangeByte-EraseBytes-ChangeBit-CrossOver-EraseBytes-CrossOver-ChangeBit-ChangeBinInt-EraseBytes-InsertByte-InsertRepeatedBytes-InsertByte-InsertByte-ChangeByte-ChangeBinInt-ChangeBit-CrossOver-ChangeByte-CrossOver-EraseBytes-ChangeByte-ShuffleBytes-ChangeBit-ChangeBit-ShuffleBytes-CopyPart-ChangeByte-PersAutoDict-ChangeBit-ChangeByte-InsertRepeatedBytes-CMP-CrossOver-ChangeByte-EraseBytes-ShuffleBytes-CrossOver-ShuffleBytes-ChangeBinInt-ChangeBinInt-CopyPart-PersAutoDict-ShuffleBytes-ChangeBit-CopyPart-ShuffleBytes-CopyPart-EraseBytes-ChangeByte-ChangeBit-ChangeBit-ChangeBinInt-ChangeByte-CopyPart-EraseBytes-ChangeBinInt-EraseBytes-EraseBytes-PersAutoDict-CMP-PersAutoDict-CrossOver-CrossOver-ChangeBit-CrossOver-PersAutoDict-CrossOver-CopyPart-ChangeByte-EraseBytes-ChangeByte-ShuffleBytes-ChangeByte-ChangeByte-CrossOver-ChangeBit-EraseBytes-ChangeByte-EraseBytes-ChangeBinInt-CrossOver-CrossOver-EraseBytes-ChangeBinInt-CrossOver-ChangeBit-ShuffleBytes-ChangeBit-ChangeByte-EraseBytes-ChangeBit-CrossOver-CrossOver-CrossOver-ChangeByte-ChangeBit-ShuffleBytes-ChangeBit-ChangeBit-EraseBytes-CrossOver-CrossOver-CopyPart-ShuffleBytes-ChangeByte-ChangeByte-CopyPart-CrossOver-CopyPart-CrossOver-CrossOver-EraseBytes-EraseBytes-ShuffleBytes-InsertRepeatedBytes-ChangeBit-CopyPart-Custom- DE: "\xfe\xff\xff\xfc"-"\x00\x00\x00\x00"-"F\x00"-"\xf3\xff\xff\xff"-"St9exception"-"_\x00\x00\x00"-"\xf6\xff\xff\xff"-"\xfe\xff\xff\xff"-"\x00\x00\x00\x00"-"p\x02\x00\x00\x00\x00\x00\x00"-"\xfe\xff\xff\xfb"-"\xff\xff"-"\xff\xff\xff\xff"-"\x01\x00\x00\x07"-"\xfe\xff\xff\xfe"-
These are prohibitively large and of limited value in the default case (when
someone is running the fuzzer, not debugging it), in my opinion.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D86658
Add the implementation of __isOSVersionAtLeast for Android. Currently,
only the major version is checked against the API level of the platform
which is an integer. The API level is retrieved by reading the system
property ro.build.version.sdk (and optionally ro.build.version.codename
to see if the platform is released or not).
Patch by jiyong@google.com
Bug: 150860940
Bug: 134795810
Test: m
Reviewed By: srhines
Differential Revision: https://reviews.llvm.org/D86596
kAllocBegMagic should be enough.
kAllocBegMagic is already set for the Secondary allocations.
kAllocBegMagic is good enough for the Primary, but it's even safer for
the Secondary allocator as all allocated block are from mmap.
Depends on D87646.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D87647
Make it atomic.
Wrap it into class.
Set it late after chunk is initialized.
Reset it soon when the chunk is still valid.
Depends on D87645.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D87646
Before D87643 they where used to optimize UsedSize(). Which was
called frequently from leak scanner.
It was also used for calls from QuarantineCallback
but we have heavy get_allocator().Deallocate call there anyway.
Depends on D87643.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D87644
Now we have enough space in the ChunkHeader.
45 bit is enough for kMaxAllowedMallocSize.
Depends on D87642.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D87643
The check that the pointer inside of the user part of the chunk does not
adds any value, but it's the last user of AddrIsInside.
I'd like to simplify AsanChunk in followup patches.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D87642
If user thread is in the allocator, the allocator
may have no pointer into future user's part of
the allocated block. AddrIsInside ignores such
pointers and lsan reports a false memory leak.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D87552
gcov is an "Edge Profiling with Edge Counters" application according to
Optimally Profiling and Tracing Programs (1994).
The minimum number of counters necessary is |E|-(|V|-1). The unmeasured edges
form a spanning tree. Both GCC --coverage and clang -fprofile-generate leverage
this optimization. This patch implements the optimization for clang --coverage.
The produced .gcda files are much smaller now.
As reported in Bug 42535, `clang` doesn't inline atomic ops on 32-bit
Sparc, unlike `gcc` on Solaris. In a 1-stage build with `gcc`, only two
testcases are affected (currently `XFAIL`ed), while in a 2-stage build more
than 100 tests `FAIL` due to this issue.
The reason for this `gcc`/`clang` difference is that `gcc` on 32-bit
Solaris/SPARC defaults to `-mpcu=v9` where atomic ops are supported, unlike
with `clang`'s default of `-mcpu=v8`. This patch changes `clang` to use
`-mcpu=v9` on 32-bit Solaris/SPARC, too.
Doing so uncovered two bugs:
`clang -m32 -mcpu=v9` chokes with any Solaris system headers included:
/usr/include/sys/isa_defs.h:461:2: error: "Both _ILP32 and _LP64 are defined"
#error "Both _ILP32 and _LP64 are defined"
While `clang` currently defines `__sparcv9` in a 32-bit `-mcpu=v9`
compilation, neither `gcc` nor Studio `cc` do. In fact, the Studio 12.6
`cc(1)` man page clearly states:
These predefinitions are valid in all modes:
[...]
__sparcv8 (SPARC)
__sparcv9 (SPARC -m64)
At the same time, the patch defines `__GCC_HAVE_SYNC_COMPARE_AND_SWAP_[1248]`
for a 32-bit Sparc compilation with any V9 cpu. I've also changed
`MaxAtomicInlineWidth` for V9, matching what `gcc` does and the Oracle
Developer Studio 12.6: C User's Guide documents (Ch. 3, Support for Atomic
Types, 3.1 Size and Alignment of Atomic C Types).
The two testcases that had been `XFAIL`ed for Bug 42535 are un-`XFAIL`ed
again.
Tested on `sparcv9-sun-solaris2.11` and `amd64-pc-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D86621
Update both thread and stack.
Update thread and stack as atomic operation.
Keep all 32bit of TID as now we have enough bits.
Depends on D87135.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D87217
An upcoming change to Scudo will change how we use the TLS slot
in tsd_shared.h, which will be a little easier to deal with if
we can remove the code path that calls pthread_getspecific and
pthread_setspecific. The only known user of this code path is Fuchsia.
We can't eliminate this code path by making Fuchsia use ELF TLS
because although Fuchsia supports ELF TLS, it is not supported within
libc itself. To address this, Roland McGrath on the Fuchsia team has
proposed that Scudo will optionally call a platform-provided function
to access a TLS slot reserved for Scudo. Android also has a reserved
TLS slot, but the code that accesses the TLS slot lives in Scudo.
We can eliminate some complexity and duplicated code by having Android
use the same mechanism that was proposed for Fuchsia, which is what
this change does. A separate change to Android implements it.
Differential Revision: https://reviews.llvm.org/D87420
This reverts commit 01cdab0b33.
It was causing the instrprof-darwin-exports.c test to fail.
```
Undefined symbols for architecture x86_64:
"_flush_fn_list", referenced from:
-exported_symbol[s_list] command line option
```
Previously we calculating the remainder by multiplying the
quotient and divisor and subtracting from the dividend.
__udivmod can calculate the remainder while calculating the
quotient. We just need to correct the sign afterward.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D87433
CHUNK_ALLOCATED. CHUNK_QUARANTINE are only states
which make AsanChunk useful for GetAsanChunk callers.
In either case member of AsanChunk are not useful.
Fix few cases which didn't expect nullptr. Most of the callers are already
expects nullptr.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D87135
This patch adds a new command-line option -mutation_graph_file=FILE for
debugging purposes, which traces how corpus inputs evolve during a fuzzing
run. For each new input that is added to the corpus, a new vertex corresponding
to the added input, as well as a new edge that connects its base input to itself
are written to the given file. Each vertex is labeled with the filename of the
input, and each edge is labeled with the mutation sequence that led to the input
w.r.t. its base input.
The format of the mutation graph file is the dot file format. Once prepended and
appended with "graph {" and "}", respectively, the graph becomes a valid dot
file and can be visualized.
Differential Revision: https://reviews.llvm.org/D86560
For a CFG G=(V,E), Knuth describes that by Kirchoff's circuit law, the minimum
number of counters necessary is |E|-(|V|-1). The emitted edges form a spanning
tree. libgcov emitted .gcda files leverages this optimization while clang
--coverage's doesn't.
Propagate counts by Kirchhoff's circuit law so that llvm-cov gcov can
correctly print line counts of gcc --coverage emitted files and enable
the future improvement of clang --coverage.
Fixes https://github.com/google/sanitizers/issues/1193.
AsanChunk can be uninitialized yet just after return from the secondary
allocator. If lsan starts scan just before metadata assignment it can
fail to find corresponding AsanChunk.
It should be safe to ignore this and let lsan to assume that
AsanChunk is in the beginning of the block. This block is from the
secondary allocator and created with mmap, so it should not contain
any pointers and will make lsan to miss some leaks.
Similar already happens for primary allocator. If it can't find real
AsanChunk it falls back and assume that block starts with AsanChunk.
Then if the block is already returned to allocator we have garbage in
AsanChunk and may scan dead memory hiding some leaks.
I'll fix this in D87135.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D86931
D28596 added SANITIZER_INTERFACE_WEAK_DEF which can guarantee `*_default_options` are always defined.
The weak attributes on the `__{asan,lsan,msan,ubsan}_default_options` declarations can thus be removed.
`MaybeCall*DefaultOptions` no longer need nullptr checks, so their call sites can just be replaced by `__*_default_options`.
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D87175
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
No point in making __parityti2 go through 2 calls to get to
__paritysi2.
Reviewed By: MaskRay, efriedma
Differential Revision: https://reviews.llvm.org/D87218
LLD supports -Ttext but with the option there is still a PT_LOAD at address zero
and thus the Linux kernel will map it to a different address and the test will fail.
Use --image-base instead.
`--demangle={True,False}` were accepted but disallowed after llvm-symbolizer's switch to OptTable.
(`--demangle={true,false}` were temporarily supported but they are case sensitive.)
There are no know bugs related to this, still it may fix some latent ones.
Main concerns with preexisting code:
1. Inconsistent atomic/non-atomic access to the same field.
2. Assumption that bitfield chunk_state is always the first byte without
even taking into account endianness.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D86917
There are no know bugs related to this, still it may fix some latent ones.
Main concerns with preexisting code:
1. Inconsistent atomic/non-atomic access to the same field.
2. Assumption that bitfield chunk_state is always the first byte without
even taking into account endianness.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D86917
Copied from lldb/.clang-tidy (D75810).
Most compiler-rt code actually uses variableName or variable_name but not VariableName.
Lots of functions use `__function_name` and FunctionName instead of functionName.
Just exclude readability-identifier-naming.
Since this is an internal header, we can just assume static_assert
exists.
If this doesn't upset any bots, I'll replace all uses of
COMPILER_CHECK in a follow-up.
Asan does not use metadata with primary allocators.
It should match AP64::kMetadataSize whic is 0.
Depends on D86917.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D86919
There are no know bugs related to this, still it may fix some latent ones.
Main concerns with preexisting code:
1. Inconsistent atomic/non-atomic access to the same field.
2. Assumption that bitfield chunk_state is always the first byte without
even taking into account endianness.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D86917
This patch scales the energy computed by the Entropic schedule based on the
execution time of each input. The input execution time is compared with the
average execution time of inputs in the corpus, and, based on the amount by
which they differ, the energy is scaled from 0.1x (for inputs executing slow) to
3x (for inputs executing fast). Note that the exact scaling criteria and formula
is borrowed from AFL.
On FuzzBench, this gives a sizeable throughput increase, which in turn leads to
more coverage on several benchmarks. For details, see the following report.
https://storage.googleapis.com/fuzzer-test-suite-public/exectime-report/index.html
Differential Revision: https://reviews.llvm.org/D86092
This patch adds an option "cross_over_uniform_dist", which, if 1, considers all
inputs in the corpus for the crossover input selection. More specifically, this
patch uses a uniform distribution of all inputs in the corpus for the CrossOver
input selection. Note that input selection for mutation is still fully
determined by the scheduling policy (i.e., vanilla or Entropic); the uniform
distribution only applies to the secondary input selection, only for the
crossover mutation of the base input chosen by the scheduling policy. This way
the corpus inputs that have useful fragments in them, even though they are
deprioritized by the scheduling policy, have chances of getting mixed with other
inputs that are prioritized and selected as base input for mutation.
Differential Revision: https://reviews.llvm.org/D86954
This patch adds an option "keep_seed" to keep all initial seed inputs in the
corpus. Previously, only the initial seed inputs that find new coverage were
added to the corpus, and all the other initial inputs were discarded. We
observed in some circumstances that useful initial seed inputs are discarded as
they find no new coverage, even though they contain useful fragments in them
(e.g., SQLITE3 FuzzBench benchmark). This newly added option provides a way to
keeping seed inputs in the corpus for those circumstances. With this patch, and
with -keep_seed=1, all initial seed inputs are kept in the corpus regardless of
whether they find new coverage or not. Further, these seed inputs are not
replaced with smaller inputs even if -reduce_inputs=1.
Differential Revision: https://reviews.llvm.org/D86577
Currently, libFuzzer will exit with an error message if a non-existent
directory is provided for any of the appropriate arguments. For cases
where libFuzzer is used in a specialized embedded environment, it would
be much easier to have libFuzzer create the directories for the user.
This patch accommodates for this scenario by allowing the user to provide
the argument `-create_missing_dirs=1` which makes libFuzzer attempt to
create the `artifact_prefix`, `exact_artifact_path`,
`features_dir` and/or corpus directory if they don't already exist rather
than throw an error and exit.
Split off from D84808 as requested [here](https://reviews.llvm.org/D84808#2208546).
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D86733
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
I had left this as a TODO, but it turns out it wasn't complicated.
By specifying `MAP_RESIZABLE`, it allows us to keep the VMO which we
can then use for release purposes.
`releasePagesToOS` also had to be called the "proper" way, as Fuchsia
requires the `Offset` field to be correct. This has no impact on
non-Fuchsia platforms.
Differential Revision: https://reviews.llvm.org/D86800
MemorySanitizer test fails on systems with more than 1024 CPUs.
This patch updates the test to make it work for machines that
have more than 1024 CPUs. This helps to fix errors on the PowerPC
sanitizer bot.
Reviewed By: #powerpc, nemanjai
Differential Revision: https://reviews.llvm.org/D87053
The interceptor for the block variants of the API references the
function versions (via `REAL(name##_f)`). On Linux, this accesses the
underlying "real pointer", defined by the interceptor macro. So we need
to declare interceptors in the right order to avoid undefined symbol
compiler error:
```
error: no member named 'real_dispatch_async_and_wait_f' in namespace '__tsan::__interception'
```
rdar://68181542
This patch introduces denormal result support to soft-float division
implementation unified by D85031.
Reviewed By: sepavloff
Differential Revision: https://reviews.llvm.org/D85032
Currently, libFuzzer will exit with an error message if a non-existent
directory is provided for any of the appropriate arguments. For cases
where libFuzzer is used in a specialized embedded environment, it would
be much easier to have libFuzzer create the directories for the user.
This patch accommodates for this scenario by allowing the user to provide
the argument `-create_missing_dirs=1` which makes libFuzzer attempt to
create the `artifact_prefix`, `exact_artifact_path`,
`features_dir` and/or corpus directory if they don't already exist rather
than throw an error and exit.
Split off from D84808 as requested [here](https://reviews.llvm.org/D84808#2208546).
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D86733
When using a custom mutator (e.g. thrift mutator, similar to LPM)
that calls back into libfuzzer's mutations via `LLVMFuzzerMutate`, the mutation
sequences needed to achieve new coverage can get prohibitively large.
Printing these large sequences has two downsides:
1) It makes the logs hard to understand for a human.
2) The performance cost slows down fuzzing.
In this patch I change the `PrintMutationSequence` function to take a max
number of entries, to achieve this goal. I also update `PrintStatusForNewUnit`
to default to printing only 10 entries, in the default verbosity level (1),
requiring the user to set verbosity to 2 if they want the full mutation
sequence.
For our use case, turning off verbosity is not an option, as that would also
disable `PrintStats()` which is very useful for infrastructure that analyzes
the logs in realtime. I imagine most users of libfuzzer always want those logs
in the default.
I built a fuzzer locally with this patch applied to libfuzzer.
When running with the default verbosity, I see logs like this:
#65 NEW cov: 4799 ft: 10443 corp: 41/1447Kb lim: 64000 exec/s: 1 rss: 575Mb L: 28658/62542 MS: 196 Custom-CrossOver-ChangeBit-EraseBytes-ChangeBit-ChangeBit-ChangeBit-CrossOver-ChangeBit-CrossOver- DE: "\xff\xff\xff\x0e"-"\xfe\xff\xff\x7f"-"\xfe\xff\xff\x7f"-"\x17\x00\x00\x00\x00\x00\x00\x00"-"\x00\x00\x00\xf9"-"\xff\xff\xff\xff"-"\xfa\xff\xff\xff"-"\xf7\xff\xff\xff"-"@\xff\xff\xff\xff\xff\xff\xff"-"E\x00"-
#67 NEW cov: 4810 ft: 10462 corp: 42/1486Kb lim: 64000 exec/s: 1 rss: 577Mb L: 39823/62542 MS: 135 Custom-CopyPart-ShuffleBytes-ShuffleBytes-ChangeBit-ChangeBinInt-EraseBytes-ChangeBit-ChangeBinInt-ChangeBit- DE: "\x01\x00\x00\x00\x00\x00\x01\xf1"-"\x00\x00\x00\x07"-"\x00\x0d"-"\xfd\xff\xff\xff"-"\xfe\xff\xff\xf4"-"\xe3\xff\xff\xff"-"\xff\xff\xff\xf1"-"\xea\xff\xff\xff"-"\x00\x00\x00\xfd"-"\x01\x00\x00\x05"-
Staring hard at the logs it's clear that the cap of 10 is applied.
When running with verbosity level 2, the logs look like the below:
#66 NEW cov: 4700 ft: 10188 corp: 37/1186Kb lim: 64000 exec/s: 2 rss: 509Mb L: 47616/61231 MS: 520 Custom-CopyPart-ChangeBinInt-ChangeBit-ChangeByte-EraseBytes-PersAutoDict-CopyPart-ShuffleBytes-ChangeBit-ShuffleBytes-CopyPart-EraseBytes-CopyPart-ChangeBinInt-CopyPart-ChangeByte-ShuffleBytes-ChangeBinInt-ShuffleBytes-ChangeBit-CMP-ShuffleBytes-ChangeBit-CrossOver-ChangeBinInt-ChangeByte-ShuffleBytes-CrossOver-EraseBytes-ChangeBinInt-InsertRepeatedBytes-PersAutoDict-InsertRepeatedBytes-InsertRepeatedBytes-CrossOver-ChangeByte-ShuffleBytes-CopyPart-ShuffleBytes-CopyPart-CrossOver-ChangeBit-ShuffleBytes-CrossOver-PersAutoDict-ChangeByte-ChangeBit-ShuffleBytes-CrossOver-ChangeByte-EraseBytes-CopyPart-ChangeBinInt-PersAutoDict-CrossOver-ShuffleBytes-CrossOver-CrossOver-EraseBytes-CrossOver-EraseBytes-CrossOver-ChangeBit-ChangeBinInt-ChangeByte-EraseBytes-ShuffleBytes-ShuffleBytes-ChangeBit-EraseBytes-ChangeBinInt-ChangeBit-ChangeBinInt-CopyPart-EraseBytes-PersAutoDict-EraseBytes-CopyPart-ChangeBinInt-ChangeByte-CrossOver-ChangeBinInt-ShuffleBytes-PersAutoDict-PersAutoDict-ChangeBinInt-CopyPart-ChangeBinInt-CrossOver-ChangeBit-ChangeBinInt-CopyPart-ChangeByte-ChangeBit-CopyPart-CrossOver-ChangeByte-ChangeBit-ChangeByte-ShuffleBytes-CMP-ChangeBit-CopyPart-ChangeBit-ChangeByte-ChangeBinInt-PersAutoDict-ChangeBinInt-CrossOver-ChangeBinInt-ChangeBit-ChangeBinInt-ChangeBinInt-PersAutoDict-ChangeBinInt-ChangeBinInt-ChangeByte-CopyPart-ShuffleBytes-ChangeByte-ChangeBit-ChangeByte-ChangeByte-EraseBytes-CrossOver-ChangeByte-ChangeByte-EraseBytes-EraseBytes-InsertRepeatedBytes-ShuffleBytes-CopyPart-CopyPart-ChangeBit-ShuffleBytes-PersAutoDict-ShuffleBytes-ChangeBit-ChangeByte-ChangeBit-ShuffleBytes-ChangeByte-ChangeBinInt-CrossOver-ChangeBinInt-ChangeBit-EraseBytes-CopyPart-ChangeByte-CrossOver-EraseBytes-CrossOver-ChangeByte-ShuffleBytes-ChangeByte-ChangeBinInt-CrossOver-ChangeByte-InsertRepeatedBytes-InsertByte-ShuffleBytes-PersAutoDict-ChangeBit-ChangeByte-ChangeBit-ShuffleBytes-ShuffleBytes-CopyPart-ShuffleBytes-EraseBytes-ShuffleBytes-ShuffleBytes-CrossOver-ChangeBinInt-CopyPart-CopyPart-CopyPart-EraseBytes-EraseBytes-ChangeByte-ChangeBinInt-ShuffleBytes-CMP-InsertByte-EraseBytes-ShuffleBytes-CopyPart-ChangeBit-CrossOver-CopyPart-CopyPart-ShuffleBytes-ChangeByte-ChangeByte-ChangeBinInt-EraseBytes-ChangeByte-ChangeBinInt-ChangeBit-ChangeBit-ChangeByte-ShuffleBytes-PersAutoDict-PersAutoDict-CMP-ChangeBit-ShuffleBytes-PersAutoDict-ChangeBinInt-EraseBytes-EraseBytes-ShuffleBytes-ChangeByte-ShuffleBytes-ChangeBit-EraseBytes-CMP-ShuffleBytes-ChangeByte-ChangeBinInt-EraseBytes-ChangeBinInt-ChangeByte-EraseBytes-ChangeByte-CrossOver-ShuffleBytes-EraseBytes-EraseBytes-ShuffleBytes-ChangeBit-EraseBytes-CopyPart-ShuffleBytes-ShuffleBytes-CrossOver-CopyPart-ChangeBinInt-ShuffleBytes-CrossOver-InsertByte-InsertByte-ChangeBinInt-ChangeBinInt-CopyPart-EraseBytes-ShuffleBytes-ChangeBit-ChangeBit-EraseBytes-ChangeByte-ChangeByte-ChangeBinInt-CrossOver-ChangeBinInt-ChangeBinInt-ShuffleBytes-ShuffleBytes-ChangeByte-ChangeByte-ChangeBinInt-ShuffleBytes-CrossOver-EraseBytes-CopyPart-CopyPart-CopyPart-ChangeBit-ShuffleBytes-ChangeByte-EraseBytes-ChangeByte-InsertRepeatedBytes-InsertByte-InsertRepeatedBytes-PersAutoDict-EraseBytes-ShuffleBytes-ChangeByte-ShuffleBytes-ChangeBinInt-ShuffleBytes-ChangeBinInt-ChangeBit-CrossOver-CrossOver-ShuffleBytes-CrossOver-CopyPart-CrossOver-CrossOver-CopyPart-ChangeByte-ChangeByte-CrossOver-ChangeBit-ChangeBinInt-EraseBytes-ShuffleBytes-EraseBytes-CMP-PersAutoDict-PersAutoDict-InsertByte-ChangeBit-ChangeByte-CopyPart-CrossOver-ChangeByte-ChangeBit-ChangeByte-CopyPart-ChangeBinInt-EraseBytes-CrossOver-ChangeBit-CrossOver-PersAutoDict-CrossOver-ChangeByte-CrossOver-ChangeByte-ChangeByte-CrossOver-ShuffleBytes-CopyPart-CopyPart-ShuffleBytes-ChangeByte-ChangeByte-ChangeBinInt-ChangeBinInt-ChangeBinInt-ChangeBinInt-ShuffleBytes-CrossOver-ChangeBinInt-ShuffleBytes-ChangeBit-PersAutoDict-ChangeBinInt-ShuffleBytes-ChangeBinInt-ChangeByte-CrossOver-ChangeBit-CopyPart-ChangeBit-ChangeBit-CopyPart-ChangeByte-PersAutoDict-ChangeBit-ShuffleBytes-ChangeByte-ChangeBit-CrossOver-ChangeByte-CrossOver-ChangeByte-CrossOver-ChangeBit-ChangeByte-ChangeBinInt-PersAutoDict-CopyPart-ChangeBinInt-ChangeBit-CrossOver-ChangeBit-PersAutoDict-ShuffleBytes-EraseBytes-CrossOver-ChangeByte-ChangeBinInt-ShuffleBytes-ChangeBinInt-InsertRepeatedBytes-PersAutoDict-CrossOver-ChangeByte-Custom-PersAutoDict-CopyPart-CopyPart-ChangeBinInt-ShuffleBytes-ChangeBinInt-ChangeBit-ShuffleBytes-CrossOver-CMP-ChangeByte-CopyPart-ShuffleBytes-CopyPart-CopyPart-CrossOver-CrossOver-CrossOver-ShuffleBytes-ChangeByte-ChangeBinInt-ChangeBit-ChangeBit-ChangeBit-ChangeByte-EraseBytes-ChangeByte-ChangeBit-ChangeByte-ChangeByte-CopyPart-PersAutoDict-ChangeBinInt-PersAutoDict-PersAutoDict-PersAutoDict-CopyPart-CopyPart-CrossOver-ChangeByte-ChangeBinInt-ShuffleBytes-ChangeBit-CopyPart-EraseBytes-CopyPart-CopyPart-CrossOver-ChangeByte-EraseBytes-ShuffleBytes-ChangeByte-CopyPart-EraseBytes-CopyPart-CrossOver-ChangeBinInt-ChangeBinInt-InsertByte-ChangeBinInt-ChangeBit-ChangeByte-CopyPart-ChangeByte-EraseBytes-ChangeByte-ChangeBit-ChangeByte-ShuffleBytes-CopyPart-ChangeBinInt-EraseBytes-CrossOver-ChangeBit-ChangeBit-CrossOver-EraseBytes-ChangeBinInt-CopyPart-CopyPart-ChangeBinInt-ChangeBit-EraseBytes-InsertRepeatedBytes-EraseBytes-ChangeBit-CrossOver-CrossOver-EraseBytes-EraseBytes-ChangeByte-CopyPart-CopyPart-ShuffleBytes-ChangeByte-ChangeBit-ChangeByte-EraseBytes-ChangeBit-ChangeByte-ChangeByte-CrossOver-CopyPart-EraseBytes-ChangeByte-EraseBytes-ChangeByte-ShuffleBytes-ShuffleBytes-ChangeByte-CopyPart-ChangeByte-ChangeByte-ChangeBit-CopyPart-ChangeBit-ChangeBinInt-CopyPart-ShuffleBytes-ChangeBit-ChangeBinInt-ChangeBit-EraseBytes-CMP-CrossOver-CopyPart-ChangeBinInt-CrossOver-CrossOver-CopyPart-CrossOver-CrossOver-InsertByte-InsertByte-CopyPart-Custom- DE: "warn"-"\x00\x00\x00\x80"-"\xfe\xff\xff\xfb"-"\xff\xff"-"\x10\x00\x00\x00"-"\xfe\xff\xff\xff"-"\xff\xff\xff\xf6"-"U\x01\x00\x00\x00\x00\x00\x00"-"\xd9\xff\xff\xff"-"\xfe\xff\xff\xea"-"\xf0\xff\xff\xff"-"\xfc\xff\xff\xff"-"warn"-"\xff\xff\xff\xff"-"\xfe\xff\xff\xfb"-"\x00\x00\x00\x80"-"\xfe\xff\xff\xf1"-"\xfe\xff\xff\xea"-"\x00\x00\x00\x00\x00\x00\x012"-"\xe2\x00"-"\xfb\xff\xff\xff"-"\x00\x00\x00\x00"-"\xe9\xff\xff\xff"-"\xff\xff"-"\x00\x00\x00\x80"-"\x01\x00\x04\xc9"-"\xf0\xff\xff\xff"-"\xf9\xff\xff\xff"-"\xff\xff\xff\xff\xff\xff\xff\x12"-"\xe2\x00"-"\xfe\xff\xff\xff"-"\xfe\xff\xff\xea"-"\xff\xff\xff\xff"-"\xf4\xff\xff\xff"-"\xe9\xff\xff\xff"-"\xf1\xff\xff\xff"-
#48 NEW cov: 4502 ft: 9151 corp: 27/750Kb lim: 64000 exec/s: 2 rss: 458Mb L: 50772/50772 MS: 259 ChangeByte-ShuffleBytes-ChangeBinInt-ChangeByte-ChangeByte-ChangeByte-ChangeByte-ChangeBit-CopyPart-CrossOver-CopyPart-ChangeByte-CrossOver-CopyPart-ChangeBit-ChangeByte-EraseBytes-ChangeByte-CopyPart-CopyPart-CopyPart-ChangeBit-EraseBytes-ChangeBinInt-CrossOver-CopyPart-CrossOver-CopyPart-ChangeBit-ChangeByte-ChangeBit-InsertByte-CrossOver-InsertRepeatedBytes-InsertRepeatedBytes-InsertRepeatedBytes-ChangeBinInt-EraseBytes-InsertRepeatedBytes-InsertByte-ChangeBit-ShuffleBytes-ChangeBit-ChangeBit-CopyPart-ChangeBit-ChangeByte-CrossOver-ChangeBinInt-ChangeByte-CrossOver-CMP-ChangeByte-CrossOver-ChangeByte-ShuffleBytes-ShuffleBytes-ChangeByte-ChangeBinInt-CopyPart-EraseBytes-CrossOver-ChangeBit-ChangeBinInt-InsertByte-ChangeBit-CopyPart-ChangeBinInt-ChangeByte-CrossOver-ChangeBit-EraseBytes-CopyPart-ChangeBinInt-ChangeBit-ChangeBit-ChangeByte-CopyPart-ChangeBinInt-CrossOver-PersAutoDict-ChangeByte-ChangeBit-ChangeByte-ChangeBinInt-ChangeBinInt-EraseBytes-CopyPart-CopyPart-ChangeByte-ChangeByte-EraseBytes-PersAutoDict-CopyPart-ChangeByte-ChangeByte-EraseBytes-CrossOver-CopyPart-CopyPart-CopyPart-ChangeByte-ChangeBit-CMP-CopyPart-ChangeBinInt-ChangeBinInt-CrossOver-ChangeBit-ChangeBit-EraseBytes-ChangeByte-ShuffleBytes-ChangeBit-ChangeBinInt-CMP-InsertRepeatedBytes-CopyPart-Custom-ChangeByte-CrossOver-EraseBytes-ChangeBit-CopyPart-CrossOver-CMP-ShuffleBytes-EraseBytes-CrossOver-PersAutoDict-ChangeByte-CrossOver-CopyPart-CrossOver-CrossOver-ShuffleBytes-ChangeBinInt-CrossOver-ChangeBinInt-ShuffleBytes-PersAutoDict-ChangeByte-EraseBytes-ChangeBit-CrossOver-EraseBytes-CrossOver-ChangeBit-ChangeBinInt-EraseBytes-InsertByte-InsertRepeatedBytes-InsertByte-InsertByte-ChangeByte-ChangeBinInt-ChangeBit-CrossOver-ChangeByte-CrossOver-EraseBytes-ChangeByte-ShuffleBytes-ChangeBit-ChangeBit-ShuffleBytes-CopyPart-ChangeByte-PersAutoDict-ChangeBit-ChangeByte-InsertRepeatedBytes-CMP-CrossOver-ChangeByte-EraseBytes-ShuffleBytes-CrossOver-ShuffleBytes-ChangeBinInt-ChangeBinInt-CopyPart-PersAutoDict-ShuffleBytes-ChangeBit-CopyPart-ShuffleBytes-CopyPart-EraseBytes-ChangeByte-ChangeBit-ChangeBit-ChangeBinInt-ChangeByte-CopyPart-EraseBytes-ChangeBinInt-EraseBytes-EraseBytes-PersAutoDict-CMP-PersAutoDict-CrossOver-CrossOver-ChangeBit-CrossOver-PersAutoDict-CrossOver-CopyPart-ChangeByte-EraseBytes-ChangeByte-ShuffleBytes-ChangeByte-ChangeByte-CrossOver-ChangeBit-EraseBytes-ChangeByte-EraseBytes-ChangeBinInt-CrossOver-CrossOver-EraseBytes-ChangeBinInt-CrossOver-ChangeBit-ShuffleBytes-ChangeBit-ChangeByte-EraseBytes-ChangeBit-CrossOver-CrossOver-CrossOver-ChangeByte-ChangeBit-ShuffleBytes-ChangeBit-ChangeBit-EraseBytes-CrossOver-CrossOver-CopyPart-ShuffleBytes-ChangeByte-ChangeByte-CopyPart-CrossOver-CopyPart-CrossOver-CrossOver-EraseBytes-EraseBytes-ShuffleBytes-InsertRepeatedBytes-ChangeBit-CopyPart-Custom- DE: "\xfe\xff\xff\xfc"-"\x00\x00\x00\x00"-"F\x00"-"\xf3\xff\xff\xff"-"St9exception"-"_\x00\x00\x00"-"\xf6\xff\xff\xff"-"\xfe\xff\xff\xff"-"\x00\x00\x00\x00"-"p\x02\x00\x00\x00\x00\x00\x00"-"\xfe\xff\xff\xfb"-"\xff\xff"-"\xff\xff\xff\xff"-"\x01\x00\x00\x07"-"\xfe\xff\xff\xfe"-
These are prohibitively large and of limited value in the default case (when
someone is running the fuzzer, not debugging it), in my opinion.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D86658
The sysctlnametomib function is called from __tsan::Initialize via
__sanitizer::internal_sysctlbyname (see stack trace below). This results
in a fatal error since sysctlnametomib has not been intercepted yet.
This patch allows internal_sysctlbyname to be called before
__tsan::Initialize() has completed. On FreeBSD >= 1300045 sysctlbyname()
is a real syscall, but for older versions it calls sysctlnametomib()
followed by sysctl(). To avoid calling the intercepted version, look up
the real sysctlnametomib() followed by internal_sysctl() if the
syscall is not available.
This reduces check-sanitizer failures from 62 to 11 for me.
==34433==FATAL: ThreadSanitizer: failed to intercept sysctlnametomib
at /exports/users/alr48/sources/upstream-llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:51
name=0x7fffffffce10, namelenp=0x7fffffffce08)
at /exports/users/alr48/sources/upstream-llvm-project/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:7908
oldp=0x7fffffffcf2c, oldlenp=0x7fffffffcf20, newp=0x0, newlen=0)
at /exports/users/alr48/sources/upstream-llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp:803
at /exports/users/alr48/sources/upstream-llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp:2152
at /exports/users/alr48/sources/upstream-llvm-project/compiler-rt/lib/tsan/rtl/tsan_rtl.cpp:367
fname=0x21c731 "readlink", pc=34366042556)
at /exports/users/alr48/sources/upstream-llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:255
bufsiz=1024)
at /exports/users/alr48/sources/upstream-llvm-project/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:7151
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D85292
This patch replaces three different pre-existing implementations of
__div[sdt]f3 LibCalls with a generic one - like it is already done for
many other LibCalls.
Reviewed By: sepavloff
Differential Revision: https://reviews.llvm.org/D85031
Currently it is hard to avoid having LLVM link to the system install of
ncurses, since it uses check_library_exists to find e.g. libtinfo and
not find_library or find_package.
With this change the ncurses lib is found with find_library, which also
considers CMAKE_PREFIX_PATH. This solves an issue for the spack package
manager, where we want to use the zlib installed by spack, and spack
provides the CMAKE_PREFIX_PATH for it.
This is a similar change as https://reviews.llvm.org/D79219, which just
landed in master.
Patch By: haampie
Differential Revision: https://reviews.llvm.org/D85820
It's not undefined behavior for an unsigned left shift to overflow (i.e. to
shift bits out), but it has been the source of bugs and exploits in certain
codebases in the past. As we do in other parts of UBSan, this patch adds a
dynamic checker which acts beyond UBSan and checks other sources of errors. The
option is enabled as part of -fsanitize=integer.
The flag is named: -fsanitize=unsigned-shift-base
This matches shift-base and shift-exponent flags.
<rdar://problem/46129047>
Differential Revision: https://reviews.llvm.org/D86000
Add functions exposed via the MSAN interface to enable MSAN within
binaries that perform manual stack switching (e.g. through using fibers
or coroutines).
This functionality is analogous to the fiber APIs available for ASAN and TSAN.
Fixesgoogle/sanitizers#1232
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D86471
The introduction of find_library for ncurses caused more issues than it solved problems. The current open issue is it makes the static build of LLVM fail. It is better to revert for now, and get back to it later.
Revert "[CMake] Fix an issue where get_system_libname creates an empty regex capture on windows"
This reverts commit 1ed1e16ab8.
Revert "Fix msan build"
This reverts commit 34fe9613dd.
Revert "[CMake] Always mark terminfo as unavailable on Windows"
This reverts commit 76bf26236f.
Revert "[CMake] Fix OCaml build failure because of absolute path in system libs"
This reverts commit 8e4acb82f7.
Revert "[CMake] Don't look for terminfo libs when LLVM_ENABLE_TERMINFO=OFF"
This reverts commit 495f91fd33.
Revert "Use find_library for ncurses"
This reverts commit a52173a3e5.
Differential revision: https://reviews.llvm.org/D86521
The CrossOver mutator is meant to cross over two given buffers (referred to as
the first/second buffer henceforth). Previously InsertPartOf/CopyPartOf calls
used in the CrossOver mutator incorrectly inserted/copied part of the second
buffer into a "scratch buffer" (MutateInPlaceHere of the size
CurrentMaxMutationLen), rather than the first buffer. This is not intended
behavior, because the scratch buffer does not always (i) contain the content of
the first buffer, and (ii) have the same size as the first buffer;
CurrentMaxMutationLen is typically a lot larger than the size of the first
buffer. This patch fixes the issue by using the first buffer instead of the
scratch buffer in InsertPartOf/CopyPartOf calls.
A FuzzBench experiment was run to make sure that this change does not
inadvertently degrade the performance. The performance is largely the same; more
details can be found at:
https://storage.googleapis.com/fuzzer-test-suite-public/fixcrossover-report/index.html
This patch also adds two new tests, namely "cross_over_insert" and
"cross_over_copy", which specifically target InsertPartOf and CopyPartOf,
respectively.
- cross_over_insert.test checks if the fuzzer can use InsertPartOf to trigger
the crash.
- cross_over_copy.test checks if the fuzzer can use CopyPartOf to trigger the
crash.
These newly added tests were designed to pass with the current patch, but not
without the it (with 790878f291 these tests do not
pass). To achieve this, -max_len was intentionally given a high value. Without
this patch, InsertPartOf/CopyPartOf will generate larger inputs, possibly with
unpredictable data in it, thereby failing to trigger the crash.
The test pass condition for these new tests is narrowed down by (i) limiting
mutation depth to 1 (i.e., a single CrossOver mutation should be able to trigger
the crash) and (ii) checking whether the mutation sequence of "CrossOver-" leads
to the crash.
Also note that these newly added tests and an existing test (cross_over.test)
all use "-reduce_inputs=0" flags to prevent reducing inputs; it's easier to
force the fuzzer to keep original input string this way than tweaking
cov-instrumented basic blocks in the source code of the fuzzer executable.
Differential Revision: https://reviews.llvm.org/D85554
value-profile-load.test needs adjustment with a mutator change in
bb54bcf849, which reverted as of now, but will be
recommitted after landing this patch.
This patch makes value-profile-load.test more friendly to (and aware of) the
current value profiling strategy, which is based on the hamming as well as the
absolute distance. To this end, this patch adjusts the set of input values that
trigger an expected crash. More specifically, this patch now uses a single value
0x01effffe as a crashing input, because this value is close to values like
{0x1ffffff, 0xffffff, ...}, which are very likely to be added to the corpus per
the current hamming- and absolute-distance-based value profiling strategy. Note
that previously the crashing input values were {1234567 * {1, 2, ...}, s.t. <
INT_MAX}.
Every byte in the chosen value 0x01effeef is intentionally different; this was
to make it harder to find the value without the intermediate inputs added to the
corpus by the value profiling strategy.
Also note that LoadTest.cpp now uses a narrower condition (Size != 8) for
initial pruning of inputs, effectively preventing libFuzzer from generating
inputs longer than necessary and spending time on mutating such long inputs in
the corpus - a functionality not meant to be tested by this specific test.
Differential Revision: https://reviews.llvm.org/D86247
It isn't very wise to pass an assembly file to the compiler and tell it to compile as a C file and hope that the compiler recognizes it as assembly instead.
Simply don't mark the file as C and CMake will recognize the rest.
This was attempted earlier in https://reviews.llvm.org/D85706, but reverted due to architecture issues on Apple.
Subsequent digging revealed a similar change was done earlier for libunwind in https://reviews.llvm.org/rGb780df052dd2b246a760d00e00f7de9ebdab9d09.
Afterwards workarounds were added for MinGW and Apple:
* https://reviews.llvm.org/rGb780df052dd2b246a760d00e00f7de9ebdab9d09
* https://reviews.llvm.org/rGd4ded05ba851304b26a437896bc3962ef56f62cb
The workarounds in libunwind and compiler-rt are unified and comments added pointing to each other.
The workaround is updated to only be used for MinGW for CMake versions before 3.17, which fixed the issue (https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4287).
Additionally fixed Clang not being passed as the assembly compiler for compiler-rt runtime build.
Example error:
[525/634] Building C object lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o
FAILED: lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o
/opt/tooling/drive/host/bin/clang --target=aarch64-linux-gnu -I/opt/tooling/drive/llvm/compiler-rt/lib/tsan/.. -isystem /opt/tooling/drive/toolchain/opt/drive/toolchain/include -x c -Wall -Wno-unused-parameter -fno-lto -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 -gline-tables-only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -Wno-non-virtual-dtor -fPIE -fno-rtti -Wframe-larger-than=530 -Wglobal-constructors --sysroot=. -MD -MT lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o -MF lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o.d -o lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o -c /opt/tooling/drive/llvm/compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S
/opt/tooling/drive/llvm/compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S:29:1: error: expected identifier or '('
.section .text
^
1 error generated.
Differential Revision: https://reviews.llvm.org/D86308
The existing implementations are almost identical except for width of the
integer type.
Factor them out to int_mulo_impl.inc for better maintainability.
This patch is almost identical to D86277.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D86289
The existing implementations are almost identical except for width of the
integer type.
Factor them out to int_mulv_impl.inc for better maintainability.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D86277
Fixes a build failure in the Darwin kernel. Tested with:
% nm -mU lib/libclang_rt.cc_kext_x86_64h_osx.a | grep __llvm_profile_raw_version
rdar://67809173
Currently, libFuzzer will exit with an error message if a non-existent
corpus directory is provided. However, if a user provides a non-existent
directory for the `artifact_prefix`, `exact_artifact_path`, or
`features_dir`, libFuzzer will continue execution but silently fail to
write artifacts/features.
To improve the user experience, this PR adds validation for the existence of
all user supplied directories before executing the main fuzzing loop. If they
don't exist, libFuzzer will exit with an error message.
Patch By: dgg5503
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D84808
With the 'new' way of releasing on 32-bit, we iterate through all the
regions in between `First` and `Last`, which covers regions that do not
belong to the class size we are working with. This is effectively wasted
cycles.
With this change, we add a `SkipRegion` lambda to `releaseFreeMemoryToOS`
that will allow the release function to know when to skip a region.
For the 64-bit primary, since we are only working with 1 region, we never
skip.
Reviewed By: hctim
Differential Revision: https://reviews.llvm.org/D86399
* Make the three tests look more uniformly
* Explicitly specify types of integer and floating point literals
* Add more test cases (mostly inspired by divtf3_test.c)
- tests are added for obviously special cases such as +/-Inf, +/-0.0 and some
more implementation-specific cases such as divisor being almost 1.0
* Make NaN in the second test case of `divtf3` to be `sNaN` instead of
testing for `qNaN` again
Reviewed By: sepavloff
Differential Revision: https://reviews.llvm.org/D84932
FreeBSD doesn't provide a crypt.h header but instead defines the functions
in unistd.h. Use __has_include() to handle that case.
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D85406
FreeBSD delivers a SIGBUS signal for bad addresses rather than SIGSEGV.
Reviewed By: #sanitizers, vitalybuka, yln
Differential Revision: https://reviews.llvm.org/D85409
The dynamically linked ASan tests rely on `LD_LIBRARY_PATH` to find
`libclang_rt.asan-*.so` at runtime.
However, the Solaris runtime linker `ld.so.1` also supports more specific
variables: `LD_LIBRARY_PATH_32` and `LD_LIBRARY_PATH_64` respectively. If
those happen to be set, `LD_LIBRARY_PATH` is ignored. In such a case, all
dynamically linked ASan tests `FAIL`. For i386 alone, this affects about
200 tests.
The following patch fixes that by also setting `LD_LIBRARY_PATH_{32,64}` on
Solaris.
Tested on `amd64-pc-solaris2.11` both with only `LD_LIBRARY_PATH` set and
with `LD_LIBRARY_PATH_{32,64}` set too.
Differential Revision: https://reviews.llvm.org/D86333
Support -march=sapphirerapids for x86.
Compare with Icelake Server, it includes 14 more new features. They are
amxtile, amxint8, amxbf16, avx512bf16, avx512vp2intersect, cldemote,
enqcmd, movdir64b, movdiri, ptwrite, serialize, shstk, tsxldtrk, waitpkg.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D86503
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
libtool already produces a table of contents, and ranlib just gives
spurious errors because it doesn't understand universal binaries.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D86365
Handle NULL address argument in the `mach_vm_[de]allocate()`
interceptors and fix test: `Assignment 2` is not valid if we weren't
able to re-allocate memory.
rdar://67680613
Currently SimpleCmpTest passes after 9,831,994 trials on x86_64/Linux
when the number of given trials is 10,000,000, just a little bigger than
that. This patch modifies SimpleCmpTest.cpp so that the test passes with less
trials, reducing its chances of future failures as libFuzzer evolves. More
specifically, this patch changes a 32-bit equality check to a 8-bit equality
check, making this test pass at 4,635,303 trials.
Differential Revision: https://reviews.llvm.org/D86382
D80465 added an assembly implementation of muldi3 for RISC-V but it didn't
add it to the cmake `*_SOURCES` list, so the C implementation was being used
instead. This patch fixes that.
Differential Revision: https://reviews.llvm.org/D86036
Instead of ANDing with a one hot mask representing the bit to
be tested, we were ANDing with just the bit number. This tests
multiple bits none of them the correct one.
This caused skylake-avx512, cascadelake and cooperlake to all
be misdetected. Based on experiments with the Intel SDE, it seems
that all of these CPUs are being detected as being cooperlake.
This is bad since its the newest CPU of the 3.
We are now using a properly-substituted minimal deployment target
compiler flag (`%min_macos_deployment_target=10.11`). Enable test on
iOS and watchOS plus simulators. We are also not testing on very old
platforms anymore, so we can remove some obsolete lit infrastructure.
* Support macOS 11+ version scheme
* Standardize substitution name `%min_deployment_target=x.y`
* Remove unneeded error cases (the input version is hard-coded)
* Specify version as tuple instead of string; no need to parse it
These changes should also facilitate a future addition of a substitution
that expands to "set deployment target to current target version"
(https://reviews.llvm.org/D70151).
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D85925
We don't test on very old versions of Apple platforms anymore. The
following lit substitution concerning the minimum deployment target for
ARC support can be removed.
```
%darwin_min_target_with_full_runtime_arc_support -> 10.11
```
Differential Revision: https://reviews.llvm.org/D85803
After removing the unnecessary `-mmacosx-version-min=10.12` compiler
flag this test can run on all platforms. I confirmed that this test is
green for iOS, iOS simulator, and watchOS simulator.
Differential Revision: https://reviews.llvm.org/D85952
This reverts commit d58fd4e521. This broke
compiler-rt compilation on macOS:
codesign --sign - /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lib/clang/12.0.99/lib/darwin/libclang_rt.tsan_ios_dynamic.dylib
ld: warning: ignoring file projects/compiler-rt/lib/tsan/CMakeFiles/clang_rt.tsan_ios_dynamic.dir/rtl/tsan_rtl_amd64.S.o, building for iOS-arm64 but attempting to link with file built for iOS Simulator-x86_64
ld: warning: ignoring file projects/compiler-rt/lib/tsan/CMakeFiles/clang_rt.tsan_ios_dynamic.dir/rtl/tsan_rtl_aarch64.S.o, building for iOS-arm64 but attempting to link with file built for iOS Simulator-x86_64
Undefined symbols for architecture arm64:
"_wrap__setjmp", referenced from:
substitution__setjmp in tsan_interceptors_posix.cpp.o
"_wrap_setjmp", referenced from:
substitution_setjmp in tsan_interceptors_posix.cpp.o
"_wrap_sigsetjmp", referenced from:
substitution_sigsetjmp in tsan_interceptors_posix.cpp.o
ld: symbol(s) not found for architecture arm64
It isn't very wise to pass an assembly file to the compiler and tell it to compile as a C file and hope that the compiler recognizes it as assembly instead.
Instead enable the ASM language and mark the files as being ASM.
[525/634] Building C object lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o
FAILED: lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o
/opt/tooling/drive/host/bin/clang --target=aarch64-linux-gnu -I/opt/tooling/drive/llvm/compiler-rt/lib/tsan/.. -isystem /opt/tooling/drive/toolchain/opt/drive/toolchain/include -x c -Wall -Wno-unused-parameter -fno-lto -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 -gline-tables-only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -Wno-non-virtual-dtor -fPIE -fno-rtti -Wframe-larger-than=530 -Wglobal-constructors --sysroot=. -MD -MT lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o -MF lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o.d -o lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o -c /opt/tooling/drive/llvm/compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S
/opt/tooling/drive/llvm/compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S:29:1: error: expected identifier or '('
.section .text
^
1 error generated.
Fixed Clang not being passed as the assembly compiler for compiler-rt runtime build.
Patch By: tambre
Differential Revision: https://reviews.llvm.org/D85706
The behavior of the CrossOver mutator has changed with
bb54bcf849. This seems to affect the
value-profile-load test on Darwin. This patch provides a wider margin for
determining success of the value-profile-load test, by testing the targeted
functionality (i.e., GEP index value profile) more directly and faster. To this
end, LoadTest.cpp now uses a narrower condition (Size != 8) for initial pruning
of inputs, effectively preventing libFuzzer from generating inputs longer than
necessary and spending time on mutating such long inputs in the corpus - a
functionality not meant to be tested by this specific test.
Previously, on x86/Linux, it required 6,597,751 execs with -use_value_profile=1
and 19,605,575 execs with -use_value_profile=0 to hit the crash. With this
patch, the test passes with 174,493 execs, providing a wider margin from the
given trials of 10,000,000. Note that, without the value profile (i.e.,
-use_value_profile=0), the test wouldn't pass as it still requires 19,605,575
execs to hit the crash.
Differential Revision: https://reviews.llvm.org/D86247
InitializeInterceptors() calls dlsym(), which calls calloc(). Depending
on the allocator implementation, calloc() may invoke mmap(), which
results in a segfault since REAL(mmap) is still being resolved.
We fix this by doing a direct syscall if interceptors haven't been fully
resolved yet.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D86168
D85820 introduced a bug where LLVM_ENABLE_TERMINFO was set to true when
the library was found, even when the user had set
-DLLVM_ENABLE_TERMINFO=OFF.
Patch By: haampie
Differential Revision: https://reviews.llvm.org/D86173
`dispatch_async_and_wait()` was introduced in macOS 10.14. Let's
forward declare it to ensure we can compile the test with older SDKs and
guard execution by checking if the symbol is available. (We can't use
`__builtin_available()`, because that itself requires a higher minimum
deployment target.) We also need to specify the `-undefined
dynamic_lookup` compiler flag.
Differential Revision: https://reviews.llvm.org/D85995
`dispatch_async_and_wait()` was introduced in macOS 10.14, which is
greater than our minimal deployment target. We need to forward declare
it as a "weak import" to ensure we generate a weak reference so the TSan
dylib continues to work on older systems. We cannot simply `#include
<dispatch.h>` or use the Darwin availability macros since this file is
multi-platform.
In addition, we want to prevent building these interceptors at all when
building with older SDKs because linking always fails.
Before:
```
➤ dyldinfo -bind ./lib/clang/12.0.0/lib/darwin/libclang_rt.tsan_osx_dynamic.dylib | grep dispatch_async_and_wait
__DATA __interpose 0x000F5E68 pointer 0 libSystem _dispatch_async_and_wait_f
```
After:
```
➤ dyldinfo -bind ./lib/clang/12.0.0/lib/darwin/libclang_rt.tsan_osx_dynamic.dylib | grep dispatch_async_and_wait
__DATA __got 0x000EC0A8 pointer 0 libSystem _dispatch_async_and_wait (weak import)
__DATA __interpose 0x000F5E78 pointer 0 libSystem _dispatch_async_and_wait (weak import)
```
This is a follow-up to D85854 and should fix:
https://reviews.llvm.org/D85854#2221529
Reviewed By: kubamracek
Differential Revision: https://reviews.llvm.org/D86103
The linker errors caused by this revision have been addressed.
Add interceptors for `dispatch_async_and_wait[_f]()` which was added in
macOS 10.14. This pair of functions is similar to `dispatch_sync()`,
but does not force a context switch of the queue onto the caller thread
when the queue is active (and hence is more efficient). For TSan, we
can apply the same semantics as for `dispatch_sync()`.
From the header docs:
> Differences with dispatch_sync()
>
> When the runtime has brought up a thread to invoke the asynchronous
> workitems already submitted to the specified queue, that servicing
> thread will also be used to execute synchronous work submitted to the
> queue with dispatch_async_and_wait().
>
> However, if the runtime has not brought up a thread to service the
> specified queue (because it has no workitems enqueued, or only
> synchronous workitems), then dispatch_async_and_wait() will invoke the
> workitem on the calling thread, similar to the behaviour of functions
> in the dispatch_sync family.
Additional context:
> The guidance is to use `dispatch_async_and_wait()` instead of
> `dispatch_sync()` when it is necessary to mix async and sync calls on
> the same queue. `dispatch_async_and_wait()` does not guarantee
> execution on the caller thread which allows to reduce context switches
> when the target queue is active.
> https://gist.github.com/tclementdev/6af616354912b0347cdf6db159c37057
rdar://35757961
Reviewed By: kubamracek
Differential Revision: https://reviews.llvm.org/D85854
The CrossOver mutator is meant to cross over two given buffers (referred to as
the first/second buffer henceforth). Previously InsertPartOf/CopyPartOf calls
used in the CrossOver mutator incorrectly inserted/copied part of the second
buffer into a "scratch buffer" (MutateInPlaceHere of the size
CurrentMaxMutationLen), rather than the first buffer. This is not intended
behavior, because the scratch buffer does not always (i) contain the content of
the first buffer, and (ii) have the same size as the first buffer;
CurrentMaxMutationLen is typically a lot larger than the size of the first
buffer. This patch fixes the issue by using the first buffer instead of the
scratch buffer in InsertPartOf/CopyPartOf calls.
A FuzzBench experiment was run to make sure that this change does not
inadvertently degrade the performance. The performance is largely the same; more
details can be found at:
https://storage.googleapis.com/fuzzer-test-suite-public/fixcrossover-report/index.html
This patch also adds two new tests, namely "cross_over_insert" and
"cross_over_copy", which specifically target InsertPartOf and CopyPartOf,
respectively.
- cross_over_insert.test checks if the fuzzer can use InsertPartOf to trigger
the crash.
- cross_over_copy.test checks if the fuzzer can use CopyPartOf to trigger the
crash.
These newly added tests were designed to pass with the current patch, but not
without the it (with 790878f291 these tests do not
pass). To achieve this, -max_len was intentionally given a high value. Without
this patch, InsertPartOf/CopyPartOf will generate larger inputs, possibly with
unpredictable data in it, thereby failing to trigger the crash.
The test pass condition for these new tests is narrowed down by (i) limiting
mutation depth to 1 (i.e., a single CrossOver mutation should be able to trigger
the crash) and (ii) checking whether the mutation sequence of "CrossOver-" leads
to the crash.
Also note that these newly added tests and an existing test (cross_over.test)
all use "-reduce_inputs=0" flags to prevent reducing inputs; it's easier to
force the fuzzer to keep original input string this way than tweaking
cov-instrumented basic blocks in the source code of the fuzzer executable.
Differential Revision: https://reviews.llvm.org/D85554
Two tests `FAIL` on 32-bit sparc:
Profile-sparc :: Posix/instrprof-gcov-parallel.test
UBSan-Standalone-sparc :: TestCases/Float/cast-overflow.cpp
The failure mode is similar:
Undefined first referenced
symbol in file
__atomic_store_4 /var/tmp/instrprof-gcov-parallel-6afe8d.o
__atomic_load_4 /var/tmp/instrprof-gcov-parallel-6afe8d.o
Undefined first referenced
symbol in file
__atomic_load_1 /var/tmp/cast-overflow-72a808.o
This is a known bug: `clang` doesn't inline atomics on 32-bit sparc, unlike
`gcc`.
The patch therefore `XFAIL`s the tests.
Tested on `sparcv9-sun-solaris2.11` and `amd64-pc-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D85346
Currently it is hard to avoid having LLVM link to the system install of
ncurses, since it uses check_library_exists to find e.g. libtinfo and
not find_library or find_package.
With this change the ncurses lib is found with find_library, which also
considers CMAKE_PREFIX_PATH. This solves an issue for the spack package
manager, where we want to use the zlib installed by spack, and spack
provides the CMAKE_PREFIX_PATH for it.
This is a similar change as https://reviews.llvm.org/D79219, which just
landed in master.
Differential revision: https://reviews.llvm.org/D85820
While the instrumentation never calls dfsan_union in fast16labels mode,
the custom wrappers do. We detect fast16labels mode by checking whether
any labels have been created. If not, we must be using fast16labels
mode.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D86012
This sets some config parameters so we can run the asan tests with
llvm-lit,
e.g. `./bin/llvm-lit [...]/compiler-rt/test/asan`
Differential Revision: https://reviews.llvm.org/D83821
Otherwise, lots of these tests fail with a CHECK error similar to:
==12345==AddressSanitizer CHECK failed: compiler-rt/lib/asan/asan_posix.cpp:120 "((0)) == ((pthread_key_create(&tsd_key, destructor)))" (0x0, 0x4e)
This is because the default pthread stubs in FreeBSD's libc always
return failures (such as ENOSYS for pthread_key_create) in case the
pthread library is not linked in.
Reviewed By: arichardson
Differential Revision: https://reviews.llvm.org/D85082
Have the front-end use the `nounwind` attribute on atomic libcalls.
This prevents us from seeing `invoke __atomic_load` in MSAN, which
is problematic as it has no successor for instrumentation to be added.
Unmapping and remapping is dangerous since another thread could touch
the shadow memory while it is unmapped. But there is really no need to
unmap anyway, since mmap(MAP_FIXED) will happily clobber the existing
mapping with zeroes. This is thread-safe since the mmap() is done under
the same kernel lock as page faults are done.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D85947
Add interceptors for `dispatch_async_and_wait[_f]()` which was added in
macOS 10.14. This pair of functions is similar to `dispatch_sync()`,
but does not force a context switch of the queue onto the caller thread
when the queue is active (and hence is more efficient). For TSan, we
can apply the same semantics as for `dispatch_sync()`.
From the header docs:
> Differences with dispatch_sync()
>
> When the runtime has brought up a thread to invoke the asynchronous
> workitems already submitted to the specified queue, that servicing
> thread will also be used to execute synchronous work submitted to the
> queue with dispatch_async_and_wait().
>
> However, if the runtime has not brought up a thread to service the
> specified queue (because it has no workitems enqueued, or only
> synchronous workitems), then dispatch_async_and_wait() will invoke the
> workitem on the calling thread, similar to the behaviour of functions
> in the dispatch_sync family.
Additional context:
> The guidance is to use `dispatch_async_and_wait()` instead of
> `dispatch_sync()` when it is necessary to mix async and sync calls on
> the same queue. `dispatch_async_and_wait()` does not guarantee
> execution on the caller thread which allows to reduce context switches
> when the target queue is active.
> https://gist.github.com/tclementdev/6af616354912b0347cdf6db159c37057
rdar://35757961
Reviewed By: kubamracek
Differential Revision: https://reviews.llvm.org/D85854
base and nptr_label were swapped, which meant we were passing nptr's
shadow as the base to the operation. Usually, the shadow is 0, which
causes strtoull to guess the correct base from the string prefix (e.g.,
0x means base-16 and 0 means base-8), hiding this bug. Adjust the test
case to expose the bug.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D85935
A recent change to sanitizer_common caused us to issue the syscall
madvise(MADV_HUGEPAGE) during HWASAN initialization. This may lead to a
problem if madvise is instrumented (e.g. because libc is instrumented
or the user intercepted it). For example, on Android the syscall may
fail if the kernel does not support transparent hugepages, which leads
to an attempt to set errno in a HWASAN instrumented function. Avoid
this problem by introducing a syscall wrapper and using it to issue
this syscall.
Tested only on Linux; includes untested updates for the other
platforms.
Differential Revision: https://reviews.llvm.org/D85870
Disable huge pages in the TSan shadow regions when no_huge_pages_for_shadow == true (default).
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D85841
Similarly as for pointers, even for integers a == b is usually false.
GCC also uses this heuristic.
Reviewed By: ebrevnov
Differential Revision: https://reviews.llvm.org/D85781
When building on `sparc64-unknown-linux-gnu`, I found that a large number
of `SanitizerCommon-asan-sparc*-Linux` tests were `FAIL`ing, like
SanitizerCommon-asan-sparc-Linux :: Linux/aligned_alloc-alignment.cpp
[...]
SanitizerCommon-asan-sparcv9-Linux :: Linux/aligned_alloc-alignment.cpp
[...]
many of them due to
fatal error: error in backend: Function "_Z14User_OnSIGSEGViP9siginfo_tPv": over-aligned dynamic alloca not supported.
which breaks ASan on Sparc. Currently ASan is only built for the benefit
of `gcc` where it does work. However, when enabling the compilation in
`compiler-rt` to make certain it continues to build, I missed
`compiler-rt/test/sanitizer_common` when disabling ASan testing on Sparc
(it's not yet enabled on Solaris).
This patch fixes the issue.
Tested on `sparcv9-sun-solaris2.11` with the `sanitizer_comon` testsuite enabled.
Differential Revision: https://reviews.llvm.org/D85732
Every now and then SystemZ programs built with ASan crash with
ERROR: AddressSanitizer: stack-overflow on address 0x040000000000
for no apparent reason. The problem is that
BufferedStackTrace::UnwindFast() is specialized for SystemZ: it takes
register 14 from the frame, however, IsValidFrame() is not
specialized, and does not guarantee that frame[14] is going to be a
valid memory access.
Fix by introducing per-arch kFrameSize and using it in IsValidFrame().
Reviewed By: uweigand
Differential Revision: https://reviews.llvm.org/D85822
This fixes https://bugs.llvm.org/show_bug.cgi?id=47118. Before this change, when the sigaction interceptor prevented a signal from being changed, it also prevented the oldact output parameter from being written to. This resulted in a use-of-uninitialized-variable by any program that used sigaction for the purpose of reading signals.
This change fixes this: the regular sigaction implementation is still called, but with the act parameter nullified, preventing any changes.
Patch By: IanPudney
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D85797
Commit 9385aaa848 ("[sancov] Fix PR33732") added zeroext to
__sanitizer_cov_trace(_const)?_cmp[1248] parameters for x86_64 only,
however, it is useful on other targets, in particular, on SystemZ: it
fixes swap-cmp.test.
Therefore, use it on all targets. This is safe: if target ABI does not
require zero extension for a particular parameter, zeroext is simply
ignored. A similar change has been implemeted as part of commit
3bc439bdff ("[MSan] Add instrumentation for SystemZ"), and there were
no problems with it.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D85689
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
When one tries to minimize timeouts using -minimize_crash=1,
minimization immediately fails. The following sequence of events is
responsible for this:
[parent] SIGALRM occurs
[parent] read() returns -EINTR (or -ERESTARTSYS according to strace)
[parent] fgets() returns NULL
[parent] ExecuteCommand() closes child's stdout and returns
[child ] SIGALRM occurs
[child ] AlarmCallback() attempts to write "ALARM: ..." to stdout
[child ] Dies with SIGPIPE without calling DumpCurrentUnit()
[parent] Does not see -exact_artifact_path and exits
When minimizing, the timer in parent is not necessary, so fix by not
setting it in this case.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D85359
On iOS, when we `longjmp()` out of the signal handler, a subsequent call
to `sigaltstack()` still reports that we are executing on the signal
handler stack.
Tracking rdar://66789814
Differential Revision: https://reviews.llvm.org/D85677
Two tests currently `XPASS` on sparcv9:
Unexpectedly Passed Tests (2):
Builtins-sparcv9-sunos :: compiler_rt_logbl_test.c
Builtins-sparcv9-sunos :: divtc3_test.c
The following patch fixes this.
Tested on `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D85119
Two ubsan tests FAIL on Sparc:
UBSan-Standalone-sparc :: TestCases/TypeCheck/misaligned.cpp
UBSan-Standalone-sparcv9 :: TestCases/TypeCheck/misaligned.cpp
I've reported the details in Bug 47015, but it boils down to the fact that
the `s1` subtest actually incurs a fault on strict-alignment targets like
Sparc which UBSan doesn't expect.
This can be fixed like the `w1` subtest by compiling with
`-fno-sanitize-recover=alignment`.
Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D85433
The former function is particularly optimized for exactly the
use case we're interested in: an all-zero buffer.
This reduces the overhead of calling this function some 80% or
more. This is particularly for instrumenting code heavy with
string processing functions, like grep. An invocation of grep
with the pattern '[aeiou]k[aeiou]' has its runtime reduced by
~75% with this patch
Differential Revision: https://reviews.llvm.org/D84961
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
As pointed out in D85387, part of the comment for MapDynamicShadow
refactored to sanitizer_common in D83247 was incorrect for non-Linux
versions. Update the comment to reflect that.
Running ninja check-sanitizer fails for after that patch (commit
058f5f6fd8) with the following error:
libRTSanitizerCommon.test.nolibc.x86_64.a(sanitizer_posix.cpp.o): In
function `__sanitizer::GetNamedMappingFd(char const*, unsigned long,
int*)':
..../llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_posix.cpp:358:
undefined reference to `fcntl'
clang-12: error: linker command failed with exit code 1 (use -v to see
invocation)
This patch works around the problem by only calling fcntl if O_CLOEXEC
is not defined.
Reviewed By: plopresti
Differential Revision: https://reviews.llvm.org/D85114
When the FreeBSD qsort() implementation recurses, it does so using an
interposable function call, so we end up calling the interceptor again
and set the saved comparator to wrapped_qsort_compar. This results in an
infinite loop and a eventually a stack overflow since wrapped_qsort_compar
ends up calling itself. This means that ASAN is completely broken on
FreeBSD for programs that call qsort(). I found this while running
check-all on a FreeBSD system a ASAN-instrumented LLVM.
Fix this by checking whether we are recursing inside qsort before writing
to qsort_compar. The same bug exists in the qsort_r interceptor, so use the
same approach there. I did not test the latter since the qsort_r function
signature does not match and therefore it's not intercepted on FreeBSD/macOS.
Fixes https://llvm.org/PR46832
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D84509
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
This change adds a CMake rule to produce shared object versions of
libFuzzer (no-main). Like the static library versions, these shared
libraries have a copy of libc++ statically linked in. For i386 we don't
link with libc++ since i386 does not support mixing position-
independent and non-position-independent code in the same library.
Patch By: IanPudney
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D84947
This quietly disabled use of zlib on Windows even when building with
-DLLVM_ENABLE_ZLIB=FORCE_ON.
> Rather than handling zlib handling manually, use find_package from CMake
> to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
> HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
> set to YES, which requires the distributor to explicitly select whether
> zlib is enabled or not. This simplifies the CMake handling and usage in
> the rest of the tooling.
>
> This is a reland of abb0075 with all followup changes and fixes that
> should address issues that were reported in PR44780.
>
> Differential Revision: https://reviews.llvm.org/D79219
This reverts commit 10b1b4a231 and follow-ups
64d99cc6ab and
f9fec0447e.
* Add SystemZ to the list of supported architectures.
* XFAIL a few tests.
Coverage reporting is broken, and is not easy to fix (see comment in
coverage.test). Interaction with sanitizers needs to be investigated
more thoroughly, since they appear to reduce coverage in certain cases.
The usage pattern of Bundle variable assumes the machine is little
endian, which is not the case on SystemZ. Fix by converting Bundle to
little-endian when necessary.
These UBSan tests assert the absence of runtime errors via `count 0`,
which means "expect no output". This fails the test unnecessarily in
some environments (e.g., iOS simulator in our case). Alter the test to
be a bit more specific and "expect no error" instead of "expect no
output".
rdar://65503408
Differential Revision: https://reviews.llvm.org/D85155
GlobalISel is the default ISel for aarch64 at -O0. Prior to D78465, GlobalISel
didn't have support for dealing with address-of-global lowerings, so it fell
back to SelectionDAGISel.
HWASan Globals require special handling, as they contain the pointer tag in the
top 16-bits, and are thus outside the code model. We need to generate a `movk`
in the instruction sequence with a G3 relocation to ensure the bits are
relocated properly. This is implemented in SelectionDAGISel, this patch does
the same for GlobalISel.
GlobalISel and SelectionDAGISel differ in their lowering sequence, so there are
differences in the final instruction sequence, explained in
`tagged-globals.ll`. Both of these implementations are correct, but GlobalISel
is slightly larger code size / slightly slower (by a couple of arithmetic
instructions). I don't see this as a problem for now as GlobalISel is only on
by default at `-O0`.
Reviewed By: aemerson, arsenm
Differential Revision: https://reviews.llvm.org/D82615
Extend the memop value profile buckets to be more flexible (could accommodate a
mix of individual values and ranges) and to cover more value ranges (from 11 to
22 buckets).
Disabled behind a flag (to be enabled separately) and the existing code to be
removed later.
Differential Revision: https://reviews.llvm.org/D81682
Currently, several InstrProf tests `FAIL` on Solaris (both sparc and x86):
Profile-i386 :: Posix/instrprof-visibility.cpp
Profile-i386 :: instrprof-merging.cpp
Profile-i386 :: instrprof-set-file-object-merging.c
Profile-i386 :: instrprof-set-file-object.c
On sparc there's also
Profile-sparc :: coverage_comments.cpp
The failure mode is always the same:
error: /var/llvm/local-amd64/projects/compiler-rt/test/profile/Profile-i386/Posix/Output/instrprof-visibility.cpp.tmp: Failed to load coverage: Malformed coverage data
The error is from `llvm/lib/ProfileData/Coverage/CoverageMappingReader.cpp`
(`loadBinaryFormat`), l.926:
InstrProfSymtab ProfileNames;
std::vector<SectionRef> NamesSectionRefs = *NamesSection;
if (NamesSectionRefs.size() != 1)
return make_error<CoverageMapError>(coveragemap_error::malformed);
where .size() is 2 instead.
Looking at the executable, I find (with `elfdump -c -N __llvm_prf_names`):
Section Header[15]: sh_name: __llvm_prf_names
sh_addr: 0x8053ca5 sh_flags: [ SHF_ALLOC ]
sh_size: 0x86 sh_type: [ SHT_PROGBITS ]
sh_offset: 0x3ca5 sh_entsize: 0
sh_link: 0 sh_info: 0
sh_addralign: 0x1
Section Header[31]: sh_name: __llvm_prf_names
sh_addr: 0x8069998 sh_flags: [ SHF_WRITE SHF_ALLOC ]
sh_size: 0 sh_type: [ SHT_PROGBITS ]
sh_offset: 0x9998 sh_entsize: 0
sh_link: 0 sh_info: 0
sh_addralign: 0x1
Unlike GNU `ld` (which primarily operates on section names) the Solaris
linker, following the ELF spirit, only merges input sections into an output
section if both section name and section flags match, so two separate
sections are maintained.
The read-write one comes from `lib/clang/12.0.0/lib/sunos/libclang_rt.profile-i386.a(InstrProfilingPlatformLinux.c.o)`
while the read-only one is generated by
`llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp` (`InstrProfiling::emitNameData`)
at l.1004 where `isConstant = true`.
The easiest way to avoid the mismatch is to change the definition in
`compiler-rt/lib/profile/InstrProfilingPlatformLinux.c` to `const`.
This fixes all failures observed.
Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D85116
Rainer Orth