Now that D137666 requires 48-bit VMA for AArch64, we can switch to
SizeClassAllocator64 for a slightly more efficient allocator
(asan/lsan already switched by default).
It seems that we can pick kSpaceBeg = 0xE00000000000ULL to support both Linux
("app-15") and FreeBSD ("high memory").
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D140792
Currently, tsan's memory mappings include 4GB
for high app, 20GB for mid app, and 8GB for low
app. The high app and mid app mappings are
too small for large programs, especially if ASLR
entropy (mmap_rnd_bits) is set higher. The low app
region (for non-PIE) is too small for some of tcmalloc's
internal tests (this does not affect normal apps,
since tsan will replace malloc).
This CL increases the memory mappings to 4TB for
high app, 1.3TB for mid app, and 10TB for low app. Note
that tsan's 44-bit pointer compression/decompression imposes
a 16TB limit on the combined size of the app mappings, making
this set of mappings more or less maximal.
Differential Revision: https://reviews.llvm.org/D140923
Previously HWCAP_ATOMIC and others were being used before checking if
they were defined. This moves up all the ifndef checks to define these
macros if they are not yet defined.
Differential Revision: https://reviews.llvm.org/D141285
This commit adds compiler-rt cmake option COMPILER_RT_DISABLE_AARCH64_FMV
which, when enabled, doesn't include function multiversioning features
initilization code in 'builtins' build.
Differential Revision: https://reviews.llvm.org/D141199
The tests contain a redundant condition in the else if branch that can
be simplified with fb13dcf3431c.
Update the condition used to prevent it from getting removed.
Alive2 proof for check removal:
https://alive2.llvm.org/ce/z/iFBnsy
compiler-rt/cmake/Modules/AllSupportedArchDefs.cmake:ALL_DFSAN_SUPPORTED_ARCH
allows AArch64 but currently the instrumentation will crash.
Port Linux AArch64 memory mappings from msan but use
SizeClassAllocator64 for a slightly more efficient allocator (used by
asan/lsan). Change dfsan/lit.cfg.py to allow Linux aarch64. All tests
should pass.
* dfsan/origin_invalid.c uses x86_64 assembly. Just make it x86_64 specific.
* dfsan/interceptors.c our mallinfo interceptor takes an argument
instead of returning a struct. This does not work on AArch64 which
uses different registers for the two function types. Disable AArch64
as msan/Linux/mallinfo.cpp does.
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D140770
As part of effort to enable sanitizer common unit tests on arm64 apple devices.
Add kModuleArchARM64 as expected Arch
Differential Revision: https://reviews.llvm.org/D140567
Following tests are marked XFAIl because they are dependent on native
C complex numbers but they are not a native type for Microsoft ABI [1].
Builtins-aarch64-windows :: divmodti4_test.c
Builtins-aarch64-windows :: fixunstfdi_test.c
Builtins-aarch64-windows :: multc3_test.c
Also trampoline_setup_test.c as it runs with only non-clang compiler while
WoA LLVM buildbots use clang.
[1] https://learn.microsoft.com/en-us/cpp/c-runtime-library/complex-math-support?view=msvc-170
r249754 (2015) added this macro (not set anywhere) for an escape hatch.
This old layout has been non-working for many years (Linux
arch/x86/include/asm/elf.h ELF_ET_DYN_BASE is outside the APP range):
FATAL: Code 0x558547327980 is out of application range. Non-PIE build?
FATAL: MemorySanitizer can not mmap the shadow memory.
FATAL: Make sure to compile with -fPIE and to link with -pie.
FATAL: Disabling ASLR is known to cause this error.
FATAL: If running under GDB, try 'set disable-randomization off'.
Non-pie doesn't work either.
This patch adds support for including binary ids in an indexed profile.
It adds a new field into the header that points to the offset of the
binary id section. The binary id section consists of a size of the
section, and a list of binary ids (if they are present) that consist
of two parts: length and data.
This patch guarantees that indexed profile is backwards compatible
after adding binary ids.
Differential Revision: https://reviews.llvm.org/D135929
For many features we expect clang and compiler-rt to have a version lock
relation, yet for XRaySledEntry we have kept version<2 compatibility for more
than 2 years (I migrated away the last user mips in 2020-09 (D87977)).
I think it's fair to call an end to version<2 now. This should discourage more
work on version<2 (e.g. D140725).
Reviewed By: ianlevesque
Differential Revision: https://reviews.llvm.org/D140739
- GCC does not recognize $fcsr0, uses $r0 instead.
- GCC does not implement __builtin_thread_pointer, which can be
obtained directly through $tp.
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D140545
This allows optionals to be serialized and deserialized, and used as arguments
and return values in SPS wrapper functions.
Serialization of optional values is indicated by use of the SPSOptional tag.
SPSOptionals are serialized serialized as a bool (false for no value, true for
value) plus the serialization of the contained value if any. Serialization
to/from std::optional is included in this commit.
This commit includes updates to SimplePackedSerialization in both ORC and the
ORC runtime.
, std::optional serialization.
We are in the process of enabling sanitizer_common unit tests on arm64 for apple devices. rdar://101436019
The test `CompactRingBuffer.int64` is failing on arm64 with the error:
```==17265==ERROR: SanitizerTool failed to deallocate 0xfffffffffffff000 (-4096) bytes at address 0x000105c30000
SanitizerTool: CHECK failed: sanitizer_posix.cpp:63 "(("unable to unmap" && 0)) != (0)" (0x0, 0x0) (tid=157296)```
If page size is sufficiently larger than alignment then this code:
UnmapOrDie((void*)end, map_end - end);
end is will be greater than map_end causing the value passed to UnmapOrDie to be negative.
This is caused when GetPageSizeCached returns 16k and alignment is 8k.
map_size and what is mapped by mmap uses size and alignment which is smaller than what is calculated by end using the actual page size.
Therefore, map_end ends up being less than end.
The call to mmap is allocating sufficent page-aligned memory, because it calls RoundUp within MmapOrDieOnFatalError.
But this size is not being captured by map_size.
We can address this by rounding up map_size here to be page-aligned. This ensures that map_end will be greater than or equal to end and that it will match mmaps use of page-aligned value, and the
subsequent call to munmap will also be page-aligned.
Differential Revision: https://reviews.llvm.org/D140353
This caused lld on mac to assert when building instrumented clang (or
instrumented code in general). See comment on the code review for
reproducer.
> In many cases, we can use an alias to avoid a symbolic relocations,
> instead of using the public, interposable symbol. When the instrumented
> function is in a COMDAT, we can use a hidden alias, and still avoid
> references to discarded sections.
>
> New compiler-rt tests are Linux only for now.
>
> Previous versions of this patch allowed the compiler to name the
> generated alias, but that would only be valid when the functions were
> local. Since the alias may be used across TUs we use a more
> deterministic naming convention, and add a `.local` suffix to the alias
> name just as we do for relative vtables aliases.
>
> Reviewed By: phosek
>
> Differential Revision: https://reviews.llvm.org/D137982
This reverts commit c42e50fede53bbcce79095e7c8115f26826c81ae.
This reverts commit e43924a75145d2f9e722f74b673145c3e62bfd07.
Reason: Patch broke the MSan buildbots. More information is available on
the original phabricator review: https://reviews.llvm.org/D127812
Previously, we would be passing down -stdlib=libc++ from the Driver
to CC1 whenever the default standard library on the platform was libc++,
even if -stdlib= had not been passed to the Driver. This meant that we
would pass -stdlib=libc++ in nonsensical circumstances, such as when
compiling C code.
This logic had been added in b534ce46bd40 to make sure that header
search paths were set up properly. However, since libc++ is now the
default Standard Library on Darwin, passing this explicitly is not
required anymore. Indeed, if no -stdlib= is specified, CC1 will end
up using libc++ if it queries which standard library to use, without
having to be told.
Not passing -stdlib= at all to CC1 on Darwin should become possible
once CC1 stops relying on it to set up framework search paths.
Furthermore, this commit also removes a diagnostic checking whether the
deployment target is too old to support libc++. Nowadays, all supported
deployment targets use libc++ and compiling with libstdc++ is not
supported anymore. The Driver was the wrong place to issue this
diagnostic since it doesn't know whether libc++ will actually be linked
against (e.g. C vs C++), which would lead to spurious diagnostics.
Given that these targets are not supported anymore, we simply drop
the diagnostic instead of trying to refactor it into CC1.
This is a re-application of 6540f32db09c which had been reverted in
49dd02bd0819 because it broke a compiler-rt test. The test had broken
because we were compiling C code and passing -stdlib=libc++, which Clang
will now warn about.
rdar://103198514
Differential Revision: https://reviews.llvm.org/D139938
21U is the default group size, which demonstrates ~15mb reduction
in heap size for some highly fragmented heaps on Fuchsia, and
a general 5mb savings when devices are under no load.
Microbenchmarks show no performance regressions, but most of our
benchmarks perform no significant mallocs. So we are choosing the
default setting, and monitoring for potential performance
issues.
Reviewed By: Chia-hungDuan
Differential Revision: https://reviews.llvm.org/D140311
In many cases, we can use an alias to avoid a symbolic relocations,
instead of using the public, interposable symbol. When the instrumented
function is in a COMDAT, we can use a hidden alias, and still avoid
references to discarded sections.
New compiler-rt tests are Linux only for now.
Previous versions of this patch allowed the compiler to name the
generated alias, but that would only be valid when the functions were
local. Since the alias may be used across TUs we use a more
deterministic naming convention, and add a `.local` suffix to the alias
name just as we do for relative vtables aliases.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D137982