This reverts commit 0f73fb18ca.
Use llvm/Profile/MIBEntryDef.inc instead of relative path.
Generated the raw profile data with `-mllvm
-enable-name-compression=false` so that builbots where the reader is
built without zlib do not fail.
Also updated the test build instructions.
This patch adds support for optional memory profile information to be
included with and indexed profile. The indexed profile header adds a new
field which points to the offset of the memory profile section (if
present) in the indexed profile. For users who do not utilize this
feature the only overhead is a 64-bit offset in the header.
The memory profile section contains (1) profile metadata describing the
information recorded for each entry (2) an on-disk hashtable containing
the profile records indexed via llvm::md5(function_name). We chose to
introduce a separate hash table instead of the existing one since the
indexing for the instrumented fdo hash table is based on a CFG hash
which itself is perturbed by memprof instrumentation.
Differential Revision: https://reviews.llvm.org/D118653
This patch refactors out the MemInfoBlock definition into a macro based
header which can be included to generate enums, structus and code for
each field recorded by the memprof profiling runtime.
Differential Revision: https://reviews.llvm.org/D117722
Third attempt to fix a bot failure from
634da7a1c6 on an Android bot:
https://lab.llvm.org/buildbot#builders/77/builds/14339
My last attempt used an approach from another test where chmod was not
working of using a bad character in the path name. But it looks like
this trick only works on Windows.
Instead, restore the original version of this test before my change at
634da7a1c6 and move the bad path test to
a new test file, marking it unsupported on Android.
Attempts to fix a bot failure from
634da7a1c6 on an Android bot:
https://lab.llvm.org/buildbot#builders/77/builds/14339
It appears that the chmod is not making the directory unwritable as
expected on this system for some reason. Adopt an approach used in
compiler-rt/test/fuzzer/fuzzer-dirs.test for systems with
non-functioning chmod by including illegal characters in directory.
Add a DirExists mechanism, modeled after FileExists. Use it to guard
creation of the report path directory.
This should avoid failures running the sanitizer in a sandbox where the
file creation attempt causes hard failures, even for an existing
directory. Problem reported on D109794 for ChromeOS in sandbox
(https://issuetracker.google.com/209296420).
Differential Revision: https://reviews.llvm.org/D119495
All platforms return the main executable as the first dl_phdr_info.
FreeBSD, NetBSD, Solaris, and Linux-musl place the executable name
in the dlpi_name field of this entry. It appears that only Linux-glibc
uses the empty string.
To make this work generically on all platforms, unconditionally skip the first
object (like is currently done for FreeBSD and NetBSD). This fixes first DSO
detection on Linux-musl with clang -shared-libsan/-shared-libasan and GCC's
default. It also would likely fix detection on Solaris/Illumos if it were to
gain PIE support (since dlpi_addr would not be NULL).
Additionally, only skip the Linux VDSO on linux.
Finally, use the empty string as the "seen first dl_phdr_info"
marker rather than (char *)-1. If there was no other object, we
would try to dereference it for a string comparison.
Reviewed By: MaskRay, vitalybuka
Differential Revision: https://reviews.llvm.org/D119515
Follow-up to 458ead66dc, which replaced the bespoke CMakeLists.txt
file for building a custom instrumented libc++ with an invocation of the
runtimes build.
In the the bespoke CMakeLists.txt, the LIBCXX_CXX_ABI setting was forced
to libcxxabi, but this was not done for the CMake invocation for the
runtimes build. This would cause CMake configuration issues on platforms
where the default LIBCXX_CXX_ABI setting is not libcxxabi, such as
FreeBSD.
Add `-DLIBCXX_CXX_ABI=libcxxabi` to that invocation, to make sure the
custom instrumented libc++ always uses the expected ABI.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D119554
An infinite loop without any effects is illegal C++ and can be optimized
away by the compiler.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D119575
This is a follow up to 4f3f4d6722
("sanitizer_common: fix __sanitizer_get_module_and_offset_for_pc signature mismatch")
which fixes a similar problem for msan build.
I am getting the following error compiling a unit test for code that
uses sanitizer_common headers and googletest transitively includes
sanitizer interface headers:
In file included from third_party/gwp_sanitizers/singlestep_test.cpp:3:
In file included from sanitizer_common/sanitizer_common.h:19:
sanitizer_interface_internal.h:41:5: error: typedef redefinition with different types
('struct __sanitizer_sandbox_arguments' vs 'struct __sanitizer_sandbox_arguments')
} __sanitizer_sandbox_arguments;
common_interface_defs.h:39:3: note: previous definition is here
} __sanitizer_sandbox_arguments;
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D119546
We run bots on a shared machine and under high load
this test sometimes segfaults.
https://lab.llvm.org/buildbot/#/builders/185/builds/1368
==1952234==XRay FDR init successful.
==1952234==XRay FDR: Not flushing to file, 'no_file_flush=true'.
<...>fdr-reinit.cpp.script: line 4: 1952234 Segmentation fault
XRAY_OPTIONS="verbosity=1" <...>/fdr-reinit.cpp.tmp
Looking at the printed output I think it's happening at:
// Finally, we should signal the sibling thread to stop.
keep_going.clear(std::memory_order_release);
Disabling the test while I try to reproduce.
We are moving away from building the runtimes with LLVM_ENABLE_PROJECTS,
however the documentation was largely outdated. This commit updates all
the documentation I could find to use LLVM_ENABLE_RUNTIMES instead of
LLVM_ENABLE_PROJECTS for building runtimes.
Note that in the near future, libcxx, libcxxabi and libunwind will stop
supporting being built with LLVM_ENABLE_PROJECTS altogether. I don't know
what the plans are for other runtimes like libc, openmp and compiler-rt,
so I didn't make any changes to the documentation that would imply
something for those projects.
Once this lands, I will also cherry-pick this on the release/14.x branch
to make sure that LLVM's documentation is up-to-date and reflects what
we intend to support in the future.
Differential Revision: https://reviews.llvm.org/D119351
Summary:
This is neccessary to support solaris/sparc9 where some userspace
addresses have all top bits set, as well as, potentially, kernel memory
on aarch64.
This change does not update the compiler side (HWASan IR pass) which
needs to be done separately for the affected targets.
Reviewers: ro, vitalybuka
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D91827
Fix passing the port and IP address with the wrong endianness
in get_sock_peer_name() that causes the connect() to fail inside
without an outgoing network interface (it's trying to connect
to 1.0.0.127 instead of 127.0.0.1).
Differential Revision: https://reviews.llvm.org/D119461
We don't need precise control over the low-level behavior of these testcases so
C should be preferred for readability.
The new testcases test (1) the base dlopen case (running initializers and
deinitializers), and (2) the serial case of dlopen; dlclose; dlopen; dlclose,
where we expect the initializers and deinitializers to be run twice.
D116208 may cause a macro clash on older versions of linux, where
fs.h defines a READ macro. This is resolved by switching to a more
typical casing style for non-macro symbols.
Reapplying with changes to the symbol names in various platform
specific code, which I missed previously.
Differential Revision: https://reviews.llvm.org/D118783
D116208 may cause a macro clash on older versions of linux, where
fs.h defines a READ macro. This is resolved by switching to a more
typical casing style for non-macro symbols.
Differential Revision: https://reviews.llvm.org/D118783
As reported in Issue #41838, `clang` doesn't correctly implement `long
double` on 32-bit Solaris/SPARC: the psABI requires this to be an 128-bit
type. Four sanitizer tests currently `FAIL` for this reason.
While there is a WIP patch to fix `clang` (D89130
<https://reviews.llvm.org/D89130>), it isn't complete yet and I've hit so
many brick walls while trying to finish it that I'm unsure if I ever will.
This patch therefore `XFAIL`s those tests in the meantime.
Tested on `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D119016
Enabling `sanitizer_common` tests on Solaris (D91606
<https://reviews.llvm.org/D91606>) and SPARC (D91608
<https://reviews.llvm.org/D91608>) uncovered a sparcv9 failure
SanitizerCommon-Unit :: ./Sanitizer-sparcv9-Test/CompactRingBuffer.int64
like this:
[ RUN ] CompactRingBuffer.int64
==24576==ERROR: SanitizerTool failed to deallocate 0x2000 (8192) bytes at address 0xffffffff7f59b000
==24576==Sanitizer CHECK failed: /vol/llvm/src/llvm-project/local/compiler-rt/lib/sanitizer_common/sanitizer_posix.cpp:61 (("unable to unmap" && 0)) != (0) (0, 0)
The problem is that the original allocation via
`MmapAlignedOrDieOnFatalError` is for 4 kB, but the Solaris/sparcv9
pagesize is 8 kB. So the initial allocation is for 12 kB, rounded to a
multiple of the pagesize. Afterwards, the unneeded rest is unmapped again,
but this fails since the address is not pagesize-aligned.
This patch avoids this by aligning the end of the mapping to the pagesize.
With D91827 <https://reviews.llvm.org/D91827> added, the test `PASS`es on
`sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D91615
As described in Issue #53523, the
`DenseMapCustomTest.DefaultMinReservedSizeTest` test FAILs on Solaris/SPARC
(both 32 and 64-bit):
/vol/llvm/src/llvm-project/local/compiler-rt/lib/sanitizer_common/tests/sanitizer_dense_map_test.cpp:399:
Failure
Expected: (MemorySize) != (Map.getMemorySize()), actual: 8192 vs 8192
This happens because SPARC, unlike many other CPUs, uses an 8 kB pagesize.
Fixed by incorporating the pagesize into the calculations of
`ExpectedInitialBucketCount` and derived values.
Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D118771
The SANITIZER_GO code path reports an undefined symbol error for dlsym.
```
FAILED: projects/compiler-rt/lib/tsan/rtl/CMakeFiles/GotsanRuntimeCheck /tmp/RelA/projects/compiler-rt/lib/tsan/rtl/CMakeFiles/GotsanRuntimeCheck
```
This symbol has been exported (as an internal GLIBC_PRIVATE symbol) from libc.so.6 starting with glibc 2.34. glibc uses it internally for its libthread_db implementation to enable thread debugging on GDB, so it is unlikely to go away for now.
Fixes#52989.
Reviewed By: #sanitizers, MaskRay, vitalybuka
Differential Revision: https://reviews.llvm.org/D119007
This patch updates the MachO platform (both the ORC MachOPlatform class and the
ORC-Runtime macho_platform.* files) to use allocation actions, rather than EPC
calls, to transfer the initializer information scraped from each linked object.
Interactions between the ORC and ORC-Runtime sides of the platform are
substantially redesigned to accomodate the change.
The high-level changes in this patch are:
1. The MachOPlatform::setupJITDylib method now calls into the runtime to set up
a dylib name <-> header mapping, and a dylib state object (JITDylibState).
2. The MachOPlatformPlugin builds an allocation action that calls the
__orc_rt_macho_register_object_platform_sections and
__orc_rt_macho_deregister_object_platform_sections functions in the runtime
to register the address ranges for all "interesting" sections in the object
being allocated (TLS data sections, initializers, language runtime metadata
sections, etc.).
3. The MachOPlatform::rt_getInitializers method (the entry point in the
controller for requests from the runtime for initializer information) is
replaced by MachOPlatform::rt_pushInitializers. The former returned a data
structure containing the "interesting" section address ranges, but these are
now handled by __orc_rt_macho_register_object_platform_sections. The new
rt_pushInitializers method first issues a lookup to trigger materialization
of the "interesting" sections, then returns the dylib dependence tree rooted
at the requested dylib for dlopen to consume. (The dylib dependence tree is
returned by rt_pushInitializers, rather than being handled by some dedicated
call, because rt_pushInitializers can alter the dependence tree).
The advantage of these changes (beyond the performance advantages of using
allocation actions) is that it moves more information about the materialized
portions of the JITDylib into the executor. This tends to make the runtime
easier to reason about, e.g. the implementation of dlopen in the runtime is now
recursive, rather than relying on recursive calls in the controller to build a
linear data structure for consumption by the runtime. This change can also make
some operations more efficient, e.g. JITDylibs can be dlclosed and then
re-dlopened without having to pull all initializers over from the controller
again.
In addition to the high-level changes, there are some low-level changes to ORC
and the runtime:
* In ORC, at ExecutionSession teardown time JITDylibs are now destroyed in
reverse creation order. This is on the assumption that the ORC runtime will be
loaded into an earlier dylib that will be used by later JITDylibs. This is a
short-term solution to crashes that arose during testing when the runtime was
torn down before its users. Longer term we will likely destroy dylibs in
dependence order.
* toSPSSerializable(Expected<T> E) is updated to explicitly initialize the T
value, allowing it to be used by Ts that have explicit constructors.
* The ORC runtime now (1) attempts to track ref-counts, and (2) distinguishes
not-yet-processed "interesting" sections from previously processed ones. (1)
is necessary for standard dlopen/dlclose emulation. (2) is intended as a step
towards better REPL support -- it should enable future runtime calls that
run only newly registered initializers ("dlopen_more", "dlopen_additions",
...?).
Adds construction from std::string, an ostream &operator<< and std::hash
specialization. Also adds unit tests for each of these operations, as well as
tests for copy construction and assignment.
These new operations will be used in upcoming macho_platform patches.
Aligned new does not require size to be a multiple of alignment, so
memalign is the correct choice instead of aligned_alloc.
Fixes false reports for unaligned sizes.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D119161
Similar to 60cc1d3218 for NetBSD, add aliases and interceptors for the
following pthread related functions:
- pthread_cond_init(3)
- pthread_cond_destroy(3)
- pthread_cond_signal(3)
- pthread_cond_broadcast(3)
- pthread_cond_wait(3)
- pthread_mutex_init(3)
- pthread_mutex_destroy(3)
- pthread_mutex_lock(3)
- pthread_mutex_trylock(3)
- pthread_mutex_unlock(3)
- pthread_rwlock_init(3)
- pthread_rwlock_destroy(3)
- pthread_rwlock_rdlock(3)
- pthread_rwlock_tryrdlock(3)
- pthread_rwlock_wrlock(3)
- pthread_rwlock_trywrlock(3)
- pthread_rwlock_unlock(3)
- pthread_once(3)
- pthread_sigmask(3)
In FreeBSD's libc, a number of internal aliases of the pthread functions
are invoked, typically with an additional prefixed underscore, e.g.
_pthread_cond_init() and so on.
ThreadSanitizer needs to intercept these aliases too, otherwise some
false positive reports about data races might be produced.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D119034
Fixes segfaults on x86_64 caused by instrumented code running before
shadow is set up.
Reviewed By: pcc
Differential Revision: https://reviews.llvm.org/D118171
This fixes the following error:
sanitizer_interface_internal.h:77:7: error: conflicting types for
'__sanitizer_get_module_and_offset_for_pc'
int __sanitizer_get_module_and_offset_for_pc(
common_interface_defs.h:349:5: note: previous declaration is here
int __sanitizer_get_module_and_offset_for_pc(void *pc, char *module_path,
I am getting it on a code that uses sanitizer_common (includes internal headers),
but also transitively gets includes of the public headers in tests
via an internal version of gtest.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D118910
We (Linaro) still have the occasional failure here due
to high load on a shared buildbot machine.
We are looking into general soloutions but perhaps this
will help in the meantime.
Instead of calling asan_report.* directly from assembly code they have been replaced with corresponding asan_report.*_asm function, which call asan_report.*. All asan_report.* are now undefined weak symbols, which allows DSOs to link when z defs is used.
Reviewed By: MaskRay, morehouse
Differential Revision: https://reviews.llvm.org/D118813
I was looking around and noticed that builtins for iossim, tvossim
and watchossim was missing arm64 builds, while apple's clang
toolchain ship with these. After a bit of searching around it just
seems like these are not listed correctly in CMake to be enabled.
I enabled just arm64 since I saw that Apple clang didn't include
arm64e.
Reviewed By: t.p.northover
Differential Revision: https://reviews.llvm.org/D118759
Unfortunately, the `sanitizer_common` tests are disabled on many targets
that are supported by `sanitizer_common`, making it easy to miss issues
with that support. This patch enables SPARC testing.
Beside the enabling proper, the patch fixes (together with D91607
<https://reviews.llvm.org/D91607>) the failures of the `symbolize_pc.cpp`,
`symbolize_pc_demangle.cpp`, and `symbolize_pc_inline.cpp` tests. They
lack calls to `__builtin_extract_return_addr`. When those are added, they
`PASS` when compiled with `gcc`. `clang` incorrectly doesn't implement a
non-default `__builtin_extract_return_addr` on several targets, SPARC
included.
Because `__builtin_extract_return_addr(__builtin_return_addr(0))` is quite
a mouthful and I'm uncertain if the code needs to compile with msvc which
appparently has it's own `_ReturnAddress`, I've introduced
`__sanitizer_return_addr` to hide the difference and complexity. Because
on 32-bit SPARC `__builtin_extract_return_addr` differs when the calling
function returns a struct, I've added a testcase for that.
There are a couple more tests failing on SPARC that I will deal with
separately.
Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D91608
Snehasish Kumar