This allows building the compiler builtins library for the Armv8-M
Baseline architecture. It can be built in the same way as other
baremetal targets using the appropriate '--target' flag
(e.g. --target=armv8m.base-eabi).
NOTE: As with the other Cortex-M targets, only the builtins library is
supported. There is no support for sanitizers, etc.
The armv8m.base architecture is a superset of armv6m, so adding it to
the cmake files using thumb1_SOURCES is almost enough for it to compile.
Minor changes are needed to divsi3 and udivsi3, because armv8m.base does
have support for div instructions but not mov with an immediate operand.
Reviewed By: MaskRay, peter.smith
Differential Revision: https://reviews.llvm.org/D143297
This patch adds support for recording BuildIds usng the sanitizer
ListOfModules API. We add another entry to the SegmentEntry struct and
change the memprof raw version.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D145190
This patch adds support for recording BuildIds usng the sanitizer
ListOfModules API. We add another entry to the SegmentEntry struct and
change the memprof raw version.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D145190
The test currently crashes as:
AddressSanitizer: CHECK failed: asan_poisoning.cpp:38 "((AddrIsAlignedByGranularity(addr))) != (0)"
Main stack address/size don't have to be aligned on asan shadow granularity.
Align stack bottom.
Reviewed By: melver, vitalybuka
Differential Revision: https://reviews.llvm.org/D145799
"Interceptors" in this file aren't like the traditional interceptors
used by other sanitizers like asan. They're simply aliases to the
equivalent __sanitizer_* functions.
This also removes the WRAP(FN) declaration since it just creates
declarations for __interceptor_* functions but they seem to be unused.
Differential Revision: https://reviews.llvm.org/D145718
/data/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:138:9: error: out-of-line definition of 'Fuzzer' does not match any declaration in 'fuzzer::Fuzzer'
Fuzzer::Fuzzer(UserCallback CB, InputCorpus &Corpus, MutationDispatcher &MD,
^~~~~~
/data/llvm-project/compiler-rt/lib/fuzzer/FuzzerInternal.h:35:10: note: type of 4th parameter of member declaration does not match definition ('fuzzer::FuzzingOptions &' vs 'const fuzzer::FuzzingOptions &')
FuzzingOptions &Options);
^
1 error generated.
On Android, the _COARSE version of clock_gettime is about twice as fast.
Therefore, add a getMonotonicTimeFast function that is used in the
releaseToOSMaybe functions.
Reviewed By: Chia-hungDuan
Differential Revision: https://reviews.llvm.org/D145636
asan+lsan
We should follow suite with how asan handles this now that lsan also
works with hwasan.
Differential Revision: https://reviews.llvm.org/D145613
Instead of going through all those trailing blocks, just count the
number and increase the counter at once.
Reviewed By: cferris
Differential Revision: https://reviews.llvm.org/D145419
When compiling compiler-rt with -fsanitize=undefined and running testcases you
end up with the following warning:
UBSan: int_mulo_impl.inc:21:36: left shift of 1 by 63 places cannot be represented in type 'di_int' (aka 'long long')
This can be avoided by simply doing the shift in a matching unsigned variant of
the type.
The same kind of pattern seems to exist in int_mulv_impl.inc
This was found in an out of tree target.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D145556
Shuffle the regions' base address so that the layout of all regions is
less predictable.
Reviewed By: cferris, cryptoad
Differential Revision: https://reviews.llvm.org/D145407
This is max acceptable value with pow of 2 for DefaultSizeClassMap, the
same as for ASAN.
Reviewed By: kstoimenov
Differential Revision: https://reviews.llvm.org/D145536
Given the memory group, we are unlikely to need a huge page map to
record entire region. This CL reduces the size of default page map
buffer from 2048 to 512 and increase the number of static buffers to 2.
Reviewed By: cferris
Differential Revision: https://reviews.llvm.org/D144754
As discussed in D145428, the memprof_init_is_running check can be moved
to the end of the initialization routine to avoid intercepting
allocations during initialization. Also, the memprof_init_done flag can
be removed and replaced with memprof_inited. Finally, memprof_inited can
also be moved to the end of the method.
Tested on the existing check-memprof tests; memprof profile collection
succeeded on a large internal workload.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D145528
Without the definition, build fails on AArch64 with
> error: 'AT_HWCAP2' undeclared (first use in this function);
> did you mean 'AT_HWCAP'?
with old Glibc versions.
Differential Revision: https://reviews.llvm.org/D145494
Glibc provides the argp_parse() function for parsing command line
arguments [1].
Indicate that argc/argv are read from and arg_index is written to.
Strictly speaking, we also need to indicate that argp is read from,
but this would require describing its layout, and most people use a
static initializer there, so it's not worth the effort.
[1] https://www.gnu.org/software/libc/manual/html_node/Argp.html
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D143330
When building compiler-rt builtins for x86_64 they library will by default
also be built for i386. We unconditionally add the Float16 compile flags
since the check for Float16 support will be done using x86_64 compiler
flags, but i386 does not actually support it. Fix this by moving the
COMPILER_RT_HAS_FLOAT16 and COMPILER_RT_HAS_FLOAT16 checks to a
per-target-architecture check inside the loop (using
`check_c_source_compiles` and `cmake_{push,pop}_check_state`).
Many of the checks in the builtin-config-ix file should probably also be
changed to per-target-arch checks, but so far only the Float16 one has
caused issues. This is an alternative to D136044 which added a special case
for i386 FreeBSD.
Fixes: https://github.com/llvm/llvm-project/issues/57224
Differential Revision: https://reviews.llvm.org/D145237
`CollectDataFlow()` uses `Flags.collect_data_flow` and
`Flags.data_flow_trace` at the same time. But in the null check before
the invocation, only `Flags.collect_data_flow` is checked, and there is
no other method to make sure `Flags.data_flow_trace` is not null, so
adding a null check for `Flags.data_flow_trace`.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D145040
Some printf format strings in libfuzzer are using the wrong specifizers, fix in this commit.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D145033
The Android svelte allocator is not used, and will likely require
some configuration and experimentation to find a balanced config.
Leave the svelte config and size map so they can be used as the
basis for the future Android svelte config.
Reviewed By: Chia-hungDuan
Differential Revision: https://reviews.llvm.org/D145525
With memory group, we always mark the free blocks from the same region.
Therefore, we don't need to calculate the offset from base and determine
the region index. Also improve the way we deal with the last block in
the region so that the loop body is simpler.
Reviewed By: cferris
Differential Revision: https://reviews.llvm.org/D143303
`__sanitizer_report_error_summary` is declared `llvm/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_interface_internal.h` as being able to be overridden by the client. On darwin the sanitizer runtime uses this symbol to find references to the sanitizer libraries, so if you override it you end up with the error `=ERROR: Interceptors are not working. This may be because AddressSanitizer is loaded too late (e.g. via dlopen). Please launch the executable with:` at launch time.
Replace uses of `__sanitizer_report_error_summary` for finding the sanitizer libraries with using the address of a local function.
Reviewed By: yln, vitalybuka
Differential Revision: https://reviews.llvm.org/D144830
This change replaces the binary profiles and executables used for
testing the memprof profile reader with tests where the profiles are
generated on the fly. This reduces toil when the profile version
changes. The tests are moved from tools/llvm-profdata to
compiler-rt/test/memprof due to the following reasons:
1. Adding dependency on memprof lit.cfg.py for llvm-profdata is
preferable to adding a dependency on compiler-rt for llvm/test.
2. All the tests can now be run with `ninja check-memprof`.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D145023
This alignment guarantee enables simpler group range check while page
releasing and a potential optimization which is, now all the pointers
from the same group are also inth same region, that means the complexity
in markFreeBlocks() can be reduced as well.
Reviewed By: cferris
Differential Revision: https://reviews.llvm.org/D142931
This is a flaky test and may not test the thing it expected to verify.
E.g., it doesn't dirty the pages so the memory usage may not be reflected
on the RSS.
Reviewed By: cferris
Differential Revision: https://reviews.llvm.org/D145126
We have the heuristic to determine the threshold of doing page
releasing for smaller size classes. However, in a case that the
memory usage is bouncing between that threshold may result in
frequent try of page releasing but not returning much memory.
This CL add another heuristic to mitigate this problem by increasing
the minimum pages that potentially can be released. Note that this
heuristic is only applied on SizeClassAllocator64. SizeClassAllocator32
has a smaller group size so the overhead is smaller than 64-bit
platform.
Differential Revision: https://reviews.llvm.org/D144768
Some build bots have not been updated to the new minimal CMake version.
Reverting for now and ping the buildbot owners.
This reverts commit 44c6b905f8527635e49bb3ea97dea315f92d38ec.
This partly undoes D137724.
This change has been discussed on discourse
https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193
Note this does not remove work-arounds for older CMake versions, that
will be done in followup patches.
Reviewed By: mehdi_amini, MaskRay, ChuanqiXu, to268, thieta, tschuett, phosek, #libunwind, #libc_vendors, #libc, #libc_abi, sivachandra, philnik, zibi
Differential Revision: https://reviews.llvm.org/D144509
This adds the --check-binary-id flag that makes sure that an object file
is available for every binary ID mentioned in the given profile. This
should help make the tool more robust in CI environments where it's
expected that coverage mappings should be available for every object
contributing to the profile.
Reviewed By: gulfem
Differential Revision: https://reviews.llvm.org/D144308
