When we use selective instrumentation and instrument a file
that is not in the selected files list provided via -fprofile-list,
we generate an empty raw profile. This leads to empty_raw_profile
error when we try to read that profile. This patch fixes the issue by
generating a raw profile that contains only a profile header when
there are no counters and profile data.
A small reproducer for the above issue:
echo "src:other.cc" > code.list
clang++ -O2 -fprofile-instr-generate -fcoverage-mapping
-fprofile-list=code.list code.cc -o code
./code
llvm-profdata show default.profraw
Differential Revision: https://reviews.llvm.org/D132094
I noticed that `test/asan/Unit/lit.site.cfg.py.in` contains two typos,
using the FreeBSD forms of the `LD_*LIBRARY_PATH*` variables on Solaris.
Tested on `amd64-pc-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D132736
Fixes this test compile error:
```
<path>/compiler-rt/test/tsan/debug_alloc_stack.cpp:54:7: error: no matching function for call to '__tsan_get_alloc_stack'
__tsan_get_alloc_stack(mem, trace, num_frames, &thread_id, &thread_os_id);
^~~~~~~~~~~~~~~~~~~~~~
<path>/compiler-rt/test/tsan/debug_alloc_stack.cpp:17:16: note: candidate function not viable: no known conversion from 'uint64_t **' (aka 'unsigned long long **') to 'uint64_t *' (aka 'unsigned long long *') for 5th argument; remove &
extern "C" int __tsan_get_alloc_stack(void *addr, void **trace, size_t size,
^
<path>/compiler-rt/test/tsan/debug_alloc_stack.cpp:61:46: warning: format specifies type 'unsigned long long' but the argument has type 'uint64_t *' (aka 'unsigned long long *') [-Wformat]
fprintf(stderr, "thread os id = 0x%llx\n", thread_os_id);
~~~~ ^~~~~~~~~~~~
1 warning and 1 error generated.
```
The wrap/unwrap operations are applied to pointers after/before conversion to/from
raw addresses. They can be used to tag, untag, sign, or strip signing from
pointers. They currently default to 'rawPtr' (identity) on all platforms, but it
is expected that the default will be set based on the host architecture, e.g.
they would default to signing/stripping for arm64e.
This is the ORC runtime counterpart to f14cb494a34:
that can lead to security vulnerabilities
Also, fix a few places that were causing -Wshadow and
-Wformat-nonliteral warnings to be emitted.
This reapplies the patch that was reverted in caaafe4ae2 because it
broke Fuchsia builders.
I reverted the changes I made to InstrProfData.inc and instead renamed
the variables in InstrProfilingWriter.c. Also fixed a bug in function
add_security_warnings that was causing it to pass -Wformat-nonliteral
when the compiler doesn't support it.
Simplify InitializeOsSupport() by separating code for detecting and
enabling the tagged address ABI.
Also drop the unnecessary errno checks (regardless of errno value, we
cannot assume that tagging works if the system call failed) and ensure
prctl(PR_SET_TAGGED_ADDR_CTRL) is only called on Android, not on x86
(where arch_prctl(ARCH_ENABLE_TAGGED_ADDR, kTagBits) is used).
Depends on D132544
Differential Revision: https://reviews.llvm.org/D132545
Use a helper function to print an error message and die in the case
flags()->fail_without_syscall_abi is set.
Because x86 doesn't have `sysctl abi.tagged_addr_disabled`, do not
mention it in the error message for non-Android runtime.
Depends on D132543
Differential Revision: https://reviews.llvm.org/D132544
Move the definitions outside InitializeOsSupport(). Also remove the
undefs, as these constants won't be visible outside the .cpp file anyway.
Differential Revision: https://reviews.llvm.org/D132543
that can lead to security vulnerabilities
Also, fix a few places that were causing -Wshadow and
-Wformat-nonliteral warnings to be emitted.
This reapplies the patch that was reverted in 0d66dc57e8 because it
broke a few bots.
I made changes so that cmake checks whether some of the flags are
supported by the compiler that is used before adding them to the list.
Also, I moved function add_security_warnings to CompilerRTUtils.cmake so
that it is defined before it's used.
Differential Revision: https://reviews.llvm.org/D131714
The existing code resulted in the max size and access counts being equal
to the min. Compute the max instead (max lifetime was already correct).
Differential Revision: https://reviews.llvm.org/D132515
This commit reverts the following commits:
- 952f90b72b
- e6a0800532 (D132298)
- 176db3b3ab (D132324)
These commits caused CI instability and need to be reverted in order
to figure things out again. See the discussion in https://llvm.org/D132324
for more information.
to handle lit tools searching. Otherwise
compiler-rt depends on system environment variable PATH for lit tools
which diverge from the other LLVM projects. This reverts D83486 which
really should be implemented in LIT itself when the PATH is constructed.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D122837
that can lead to security vulnerabilities
Also, fix a few places that were causing -Wshadow and
-Wformat-nonliteral warnings to be emitted.
Differential Revision: https://reviews.llvm.org/D131714
This has been officially deprecated since D112724, meaning the
deprecation warning is present in released 14 and 15.
This makes me think that now, shortly after the 15 release is branched,
is a good time to pull the trigger.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D132324
When checking if we are cross-compiling, use `CMAKE_HOST_SYSTEM_NAME`
rather than `CMAKE_HOST_SYSTEM` which seems to have the full version
number attached.
Reviewed By: smeenai
Differential Revision: https://reviews.llvm.org/D132130
We held off on this before as `LLVM_LIBDIR_SUFFIX` conflicted with it.
Now we return this.
`LLVM_LIBDIR_SUFFIX` is kept as a deprecated way to set
`CMAKE_INSTALL_LIBDIR`. The other `*_LIBDIR_SUFFIX` are just removed
entirely.
I imagine this is too potentially-breaking to make LLVM 15. That's fine.
I have a more minimal version of this in the disto (NixOS) patches for
LLVM 15 (like previous versions). This more expansive version I will
test harder after the release is cut.
Reviewed By: sebastian-ne, ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D130586
Done according to @phosek's comments in D117537, but not done then to
separate pure refactor (that) from possible behavior change (this).
Wasn't working before, but I think that was due to an issue of mismatched variable names fixed in D110005.
Reviewed By: phosek, #libunwind, #libc_abi
Differential Revision: https://reviews.llvm.org/D117833
We've started using C++17 constructs in compiler-rt now (e.g.
string_view in ORC), but when using the bootstrapping build, we won't
inherit the C++ standard from LLVM, and compilation may fail if we
default to an older standard. Explicitly build compiler-rt with C++17 in
a standalone build, which matches what other subprojects (e.g. Clang and
LLD) do.
Mingw headers are all lowercase, and can be used for cross compilation
from case sensitive file systems.
The official Windows SDK headers aren't self-consistent wrt upper/lower
case, so those headers can't be used on case sensitive systems without
a layer providing case insensitivity anyway.
This matches other includes of windows.h throughout the codebase.
Initial platform support for COFF/x86_64.
Completed features:
* Statically linked orc runtime.
* Full linking/initialization of static/dynamic vc runtimes and microsoft stl libraries.
* SEH exception handling.
* Full static initializers support
* dlfns
* JIT side symbol lookup/dispatch
Things to note:
* It uses vc runtime libraries found in vc toolchain installations.
* Bootstrapping state is separated because when statically linking orc runtime it needs microsoft stl functions to initialize the orc runtime, but static initializers need to be ran in order to fully initialize stl libraries.
* Process symbols can't be used blidnly on msvc platform; otherwise duplicate definition error gets generated. If process symbols are used, it's destined to get out-of-reach error at some point.
* Atexit currently not handled -- will be handled in the follow-up patches.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D130479
Allows for even more savings in the binary image while simultaneously removing the name of the offending stack variable.
Depends on D131631
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D131728
The goal is to reduce the size of the MSAN with track origins binary, by making
the variable name locations constant which will allow the linker to compress
them.
Follows: https://reviews.llvm.org/D131415
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D131631
This is done by calling __msan_set_alloca_origin and providing the location of the variable by using the call stack.
This is prepatory work for dropping variable names when track-origins is enabled.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D131205
#56854 shows a backwards compatibility problem when builtins of compiler-rt don't follow ABI. We need to prevent to fall into the trap again for BF16.
Reviewed By: bkramer
Differential Revision: https://reviews.llvm.org/D131147
With the recent llvm-project C++17 switch (D130689), gwp_asan/tests may fail to
link with some versions of GCC (https://github.com/llvm/llvm-project/issues/56994):
> backtrace.cpp:(.text+0xca6): undefined reference to `gwp_asan::AllocationMetadata::kMaxTraceLengthToCollect'
I cannot reproduce this issue by myself, but notice that currently
lib/gwp_asan/*.cpp get -std=c++17 while lib/gwp_asan/tests/*.cpp don't
(therefore may use -std=g++14 default from Clang and older GCC). Using -std=c++17
for lib/gwp_asan/tests will ensure that backtrace.cpp uses inline variable and will assuredly avoid the
possible GCC issue.
In the long-term, we should add -std=c++17 to a central place like generate_compiler_rt_tests.
Reviewed By: dyung
Differential Revision: https://reviews.llvm.org/D131440
AIX 7.2 TL5 SP4 and AIX 7.3 TL0 SP2 have been released as of now.
The linker in these OS versions recognizes and properly supports
__start_SECNAME and __stop_SECNAME symbols which are needed for PGO.
This reverts commit 93bb2f16e8.
When linking scudo standalone on armv7, it can't find symbols related to
unwinding (e.g. __aeabi_unwind_cpp_pr0). This is because it is passing
--unwindlib=none. This patch hacks around the issue by adding
COMPILER_RT_UNWINDER_LINK_LIBS to the link line.
I don't know anything about scudo, so I'm not sure what the original
intention was.
See also https://github.com/llvm/llvm-project/issues/56900
Differential Revision: https://reviews.llvm.org/D131250
1dcff823db updated the ORC runtime to use std::string_view, rather than its
own placeholder class (__orc_rt::string_view), but failed to add these
includes.
b1356504e6 enabled the use of c++17 features in LLVM, which means that we can
drop the ORC runtime's placeholder string_view implemention in favor of
std::string_view.
This function could be called wih access_info & 0x20 or with
flags()->halt_on_error, in which case HandleTagMismatch returns (is not
fatal).
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D131279
Correct a bug in the code that resets shadow memory introduced as part
of a previous change for the Go race detector (D128909). The bug was
that only the most recently added shadow segment was being reset, as
opposed to the entire extent of the segment created so far. This
fixes a bug identified in Google internal testing (b/240733951).
Differential Revision: https://reviews.llvm.org/D131256
As mentioned in https://reviews.llvm.org/D121379#3690593, this
change broke the build of compiler-rt targeting powerpc using GCC.
The 32-bit powerpc target is not supposed to emit 128-bit libcalls
-- if it does, then that's a backend bug and needs to be fixed there.
This reverts commit 8f24a56a3a.
Differential Revision: https://reviews.llvm.org/D130988
The __swif5_proto and __swift5_protos sections had their meaning
inverted. Fix, and rename the arrays so it is more obvious which is
which.
Differential Revision: https://reviews.llvm.org/D131206
Instead of detecting `_Float16` support at CMake configuration time,
detect it at compile time by checking for the predefined (by the
compiler) macro `__FLT16_MAX__` instead.
This solves the issue where compiler-rt is built simultaneously for both
x86_64 and i386 targets, and the CMake configuration uses x86_64
compilation to detect `_Float16` support, while it may not be supported
by the i386 target (if it does not have SSE2).
While here, rename `COMPILERT_RT_HAS_FLOAT16` to `CRT_HAS_FLOAT16`, to
conform more to the naming style used in `int_lib.h` and `int_types.h`.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D130718
Since D92241, compiler-rt/cmake/builtin-config-ix.cmake automatically tests
the host compiler for support of _Float16 and conditionally defines
COMPILER_RT_HAS_FLOAT16. That defines the macro while the compiler-rt
builtins are being built. To also define it during the compiler-rt test
runs requires whitelisting the architecture in
compiler-rt/test/builtins/CMakeLists.txt, as done in this patch. That seems
brittle. Ideally, we'd move to a solution where the target compiler was
automatically tested as well, but I'm not sure how feasible that is with the
current CMake setup.
For now, this patch whitelists RISC-V, fixing errors in test__extendhfsf2.
Alternate solutions that fix the root issue are welcome, though.
Differential Revision: https://reviews.llvm.org/D129432
Since D92241, compiler-rt/cmake/builtin-config-ix.cmake automatically tests
the host compiler for support of _Float16 and conditionally defines
COMPILER_RT_HAS_FLOAT16. That defines the macro while the compiler-rt
builtins are being built. To also define it during the compiler-rt test
runs requires whitelisting the architecture in
compiler-rt/test/builtins/CMakeLists.txt, as done in this patch. That seems
brittle. Ideally, we'd move to a solution where the target compiler was
automatically tested as well, but I'm not sure how feasible that is with the
current CMake setup.
For now, this patch whitelists RISC-V, fixing errors in test__extendhfsf2.
Alternate solutions that fix the root issue are welcome, though.
Differential Revision: https://reviews.llvm.org/D129432
When building on Linux/sparc64, the 32-bit `libclang_rt.asan.so`,
`libclang_rt.ubsan_minimal.so`, and `libclang_rt.ubsan_standalone.so`
failed to link with undefined references to 64-bit atomics, which `clang`
cannot inline. Even D130569 <https://reviews.llvm.org/D130569> didn't help
because those libraries are linked with `-nodefaultlibs`, so dependent
libraries need to be added explicitly.
That's what this patch does.
Tested on `sparc64-unknown-linux-gnu` and `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D130571
Currently, m{platform}-version-min is default flag used to set min deployment target within compilter-rt and sanitizers.
However, clang uses flags -target and -mtargetos for setting target triple and minimum deployment targets.
-mtargetos will be the preferred flag to set min version in the future and the
${platform}-version-min flag will not be used for future platforms.
This change allows darwin platforms to use either ${platform}-min-version or -mtargetos
without breaking lit test flags that allows for overriding the default min value in lit tests
Tests using flags: 'darwin_min_target_with_tls_support', 'min_macos_deployment_target'
will no longer fail if they use mtargetos instead of version-min.
rdar://81028225
Differential Revision: https://reviews.llvm.org/D130542
Capture the computed shadow begin/end values at the point where the
shadow is first created and reuse those values on reset. Introduce new
windows-specific function "ZeroMmapFixedRegion" for zeroing out an
address space region previously returned by one of the MmapFixed*
routines; call this function (on windows) from DoResetImpl
tsan_rtl.cpp instead of MmapFixedSuperNoReserve.
See https://github.com/golang/go/issues/53539#issuecomment-1168778740
for context; intended to help with updating the syso for Go's
windows/amd64 race detector.
Differential Revision: https://reviews.llvm.org/D128909
Currently in Sema::ActOnEnumBody(...) when calculating NumPositiveBits we miss
the case where there is only a single enumerator with value zero and the case of
an empty enum. In both cases we end up with zero positive bits when in fact we
need one bit to store the value zero.
This PR updates the calculation to account for these cases.
Differential Revision: https://reviews.llvm.org/D130301
Prevent the following pathological behavior:
Since memory access handling is not synchronized with DoReset,
a thread running concurrently with DoReset can leave a bogus shadow value
that will be later falsely detected as a race. For such false races
RestoreStack will return false and we will not report it.
However, consider that a thread leaves a whole lot of such bogus values
and these values are later read by a whole lot of threads.
This will cause massive amounts of ReportRace calls and lots of
serialization. In very pathological cases the resulting slowdown
can be >100x. This is very unlikely, but it was presumably observed
in practice: https://github.com/google/sanitizers/issues/1552
If this happens, previous access sid+epoch will be the same for all of
these false races b/c if the thread will try to increment epoch, it will
notice that DoReset has happened and will stop producing bogus shadow
values. So, last_spurious_race is used to remember the last sid+epoch
for which RestoreStack returned false. Then it is used to filter out
races with the same sid+epoch very early and quickly.
It is of course possible that multiple threads left multiple bogus shadow
values and all of them are read by lots of threads at the same time.
In such case last_spurious_race will only be able to deduplicate a few
races from one thread, then few from another and so on. An alternative
would be to hold an array of such sid+epoch, but we consider such scenario
as even less likely.
Note: this can lead to some rare false negatives as well:
1. When a legit access with the same sid+epoch participates in a race
as the "previous" memory access, it will be wrongly filtered out.
2. When RestoreStack returns false for a legit memory access because it
was already evicted from the thread trace, we will still remember it in
last_spurious_race. Then if there is another racing memory access from
the same thread that happened in the same epoch, but was stored in the
next thread trace part (which is still preserved in the thread trace),
we will also wrongly filter it out while RestoreStack would actually
succeed for that second memory access.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D130269
We used to deduplicate based on the race address to prevent lots
of repeated reports about the same race.
But now we clear the shadow for the racy address in DoReportRace:
// This prevents trapping on this address in future.
for (uptr i = 0; i < kShadowCnt; i++)
StoreShadow(&shadow_mem[i], i == 0 ? Shadow::kRodata : Shadow::kEmpty);
It should have the same effect of not reporting duplicates
(and actually better because it's automatically reset when the memory is reallocated).
So drop the address deduplication code. Both simpler and faster.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D130240
ClearShadowMemoryForContextStack assumes that context contains the stack
bounds. This is not true for a context from getcontext or oucp of
swapcontext.
Reviewed By: kstoimenov
Differential Revision: https://reviews.llvm.org/D130218
This is a NFC change to factor out GCD worker thread registration via
the pthread introspection hook.
In a follow-up change we also want to register GCD workers for ASan to
make sure threads are registered before we attempt to print reports on
them.
rdar://93276353
Differential Revision: https://reviews.llvm.org/D126351
Clang has traditionally allowed C programs to implicitly convert
integers to pointers and pointers to integers, despite it not being
valid to do so except under special circumstances (like converting the
integer 0, which is the null pointer constant, to a pointer). In C89,
this would result in undefined behavior per 3.3.4, and in C99 this rule
was strengthened to be a constraint violation instead. Constraint
violations are most often handled as an error.
This patch changes the warning to default to an error in all C modes
(it is already an error in C++). This gives us better security posture
by calling out potential programmer mistakes in code but still allows
users who need this behavior to use -Wno-error=int-conversion to retain
the warning behavior, or -Wno-int-conversion to silence the diagnostic
entirely.
Differential Revision: https://reviews.llvm.org/D129881
This patch, on top of D120048 <https://reviews.llvm.org/D120048>, supports
GetTls on Solaris 11.3 and Illumos that lack `dlpi_tls_modid`. It's the
same method originally used in D91605 <https://reviews.llvm.org/D91605>,
but integrated into `GetStaticTlsBoundary`.
Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D120059
sanitizer_platform_limits_posix.h defines `__sanitizer_XDR ` if `SANITIZER_LINUX && !SANITIZER_ANDROID`, but sanitizer_platform_limits_posix.cpp tries to check it if `HAVE_RPC_XDR_H`. This coincidentally works because macOS has a broken <rpc/xdr.h> which causes `HAVE_RPC_XDR_H` to be 0, but if <rpc/xdr.h> is fixed then clang fails to compile on macOS. Restore the platform checks so that <rpc/xdr.h> can be fixed on macOS.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D130060
Depends on D129371.
It survived all GCC ASan tests.
Changes are trivial and mostly "borrowed" RISC-V logics, except that a different SHADOW_OFFSET is used.
Reviewed By: SixWeining, MaskRay, XiaodongLoong
Differential Revision: https://reviews.llvm.org/D129418
Initial libsanitizer support for LoongArch. It survived all GCC UBSan tests.
Major changes:
1. LoongArch port of Linux kernel only supports `statx` for `stat` and its families. So we need to add `statx_to_stat` and use it for `stat`-like libcalls. The logic is "borrowed" from Glibc.
2. `sanitizer_syscall_linux_loongarch64.inc` is mostly duplicated from RISC-V port, as the syscall interface is almost same.
Reviewed By: SixWeining, MaskRay, XiaodongLoong, vitalybuka
Differential Revision: https://reviews.llvm.org/D129371
This patches exposed existing incorectness of swapcontext imlementation.
swapcontext does not set oucp->uc_stack. Unpoisoning works if ucp is
from makecontext, but may try to use garbage pointers if it's from
previos swapcontext or from getcontext. Existing limit reduces
probability of garbage pointers are used.
I restore behavour which we had for years, and will look to improve
swapcontext support.
This reverts commit d0751c9725.
The compler-rt test case tsan/Linux/clone_setns.cpp fails on
PowerPC64 RHEL 7.9 targets.
Unshare fails with errno code EINVAL.
It is unclear why this happens specifically on RHEL 7.9 and no other
operating system like Ubuntu 18 or RHEL 8.4 for example.
This patch uses marcos to disable the test case for ppc64 rhel7.9
because there are no XFAIL directives to target rhel 7.9 specifically.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D130086
Use the FreeBSD AArch64 memory layout values when building for it.
These are based on the x86_64 values, scaled to take into account the
larger address space on AArch64.
Reviewed by: vitalybuka
Differential Revision: https://reviews.llvm.org/D125758
If lots of threads do lots of malloc/free and they overflow
per-pthread DenseSlabAlloc cache, it causes lots of contention:
31.97% race.old race.old [.] __sanitizer::StaticSpinMutex::LockSlow
17.61% race.old race.old [.] __tsan_read4
10.77% race.old race.old [.] __tsan::SlotLock
Optimize DenseSlabAlloc to use a lock-free stack of batches of nodes.
This way we don't take any locks in steady state at all and do only
1 push/pop per Refill/Drain.
Effect on the added benchmark:
$ TIME="%e %U %S %M" time ./test.old 36 5 2000000
34.51 978.22 175.67 5833592
32.53 891.73 167.03 5790036
36.17 1005.54 201.24 5802828
36.94 1004.76 226.58 5803188
$ TIME="%e %U %S %M" time ./test.new 36 5 2000000
26.44 720.99 13.45 5750704
25.92 721.98 13.58 5767764
26.33 725.15 13.41 5777936
25.93 713.49 13.41 5791796
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D130002
Because the call to `dlerror()` may actually want to print something, which turns into a deadlock
as showcased in #49223.
Instead rely on further call to dlsym to clear `dlerror` internal state if they
need to check the return status.
Differential Revision: https://reviews.llvm.org/D128992
The flag `-fcs-profile-generate` for enabling CSIRPGO moves the pass
`pgo-instrumentation` after inlining. Function entry coverage works fine
with this change, so remove the assert. I had originally left this
assert in because I had not tested this at the time.
Reviewed By: davidxl, MaskRay
Differential Revision: https://reviews.llvm.org/D129407
This caused build failures when building Clang and libc++ together on Mac:
fatal error: 'experimental/memory_resource' file not found
See the code review for details. Reverting until the problem and how to
solve it is better understood.
(Updates to some test files were not reverted, since they seemed
unrelated and were later updated by 340b48b267b96.)
> This is the first part of a plan to ship experimental features
> by default while guarding them behind a compiler flag to avoid
> users accidentally depending on them. Subsequent patches will
> also encompass incomplete features (such as <format> and <ranges>)
> in that categorization. Basically, the idea is that we always
> build and ship the c++experimental library, however users can't
> use what's in it unless they pass the `-funstable` flag to Clang.
>
> Note that this patch intentionally does not start guarding
> existing <experimental/FOO> content behind the flag, because
> that would merely break users that might be relying on such
> content being in the headers unconditionally. Instead, we
> should start guarding new TSes behind the flag, and get rid
> of the existing TSes we have by shipping their Standard
> counterpart.
>
> Also, this patch must jump through a few hoops like defining
> _LIBCPP_ENABLE_EXPERIMENTAL because we still support compilers
> that do not implement -funstable yet.
>
> Differential Revision: https://reviews.llvm.org/D128927
This reverts commit bb939931a1.
On a mips64el-linux-gnu system, the dynamic linker arranges TLS blocks
like:
[0] 0xfff7fe9680..0xfff7fe9684, align = 0x4
[1] 0xfff7fe9688..0xfff7fe96a8, align = 0x8
[2] 0xfff7fe96c0..0xfff7fe9e60, align = 0x40
[3] 0xfff7fe9e60..0xfff7fe9ef8, align = 0x8
Note that the dynamic linker can only put [1] at 0xfff7fe9688, not
0xfff7fe9684 or it will be misaligned. But we were comparing the
distance between two blocks with the alignment of the previous range,
causing GetStaticTlsBoundary fail to merge the consecutive blocks.
Compare against the alignment of the latter range to fix the issue.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D129112
Since the introduction of GoogleTest sharding in D122251
<https://reviews.llvm.org/D122251>, some of the Solaris sanitizer tests
have been running extremly long (up to an hour) while they took mere
seconds before. Initial investigation suggests that massive lock
contention in Solaris procfs is involved here.
However, there's an easy way to somewhat reduce the impact: while the
current `ReadProcMaps` uses `ReadFileToBuffer` to read `/proc/self/xmap`,
that function primarily caters to Linux procfs reporting file sizes of 0
while the size on Solaris is accurate. This patch makes use of that,
reducing the number of syscalls involved and reducing the runtime of
affected tests by a factor of 4.
Besides, it handles shared mappings and doesn't call `readlink` for unnamed
map entries.
Tested on `sparcv9-sun-solaris2.11` and `amd64-pc-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D129837
Lang Hames