This is a follow up to [Sanitizers][Darwin] Rename Apple macro SANITIZER_MAC -> SANITIZER_APPLE (D125816)
Performed a global search/replace as in title against LLVM sources
Differential Revision: https://reviews.llvm.org/D126263
Add support for the new crash reporter api if the headers are available. Falls back to the old API if they are not available. This change was based on [[ 0164d546d2/llvm/lib/Support/PrettyStackTrace.cpp (L111) | /llvm/lib/Support/PrettyStackTrace.cpp ]]
There is a lit for this behavior here: https://reviews.llvm.org/D96737 but is not included in this diff because it is potentially flaky.
rdar://69767688
Reviewed By: delcypher, yln
Commited by Dan Liew on behalf of Emily Shi.
Differential Revision: https://reviews.llvm.org/D96830
Checking the OS version via `GetMacosAlignedVersion()` now works in
simulators [1]. Let's use it to simplify `DyldNeedsEnvVariable()`.
[1] 3fb0de8207
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D81197
Use a struct to represent numerical versions instead of encoding release
names in an enumeration. This avoids the need to extend the enumeration
every time there is a new release.
Rename `GetMacosVersion() -> GetMacosAlignedVersion()` to better reflect
how this is used on non-MacOS platforms.
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D79970
This applies the learnings from [1]. What I intended as a simple
cleanup made me realize that the compiler-rt version checks have two
separate issues:
1) In some places (e.g., mmap flag setting) what matters is the kernel
version, not the OS version.
2) OS version checks are implemented by querying the kernel version.
This is not necessarily correct inside the simulators if the
simulator runtime isn't aligned with the host macOS.
This commit tackles 1) by adopting a separate query function for the
Darwin kernel version. 2) (and cleanups) will be dealt with in
follow-ups.
[1] https://reviews.llvm.org/D78942
rdar://63031937
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D79965
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
On macOS Mojave, the OS started using the XOR-by-a-secret-key scheme (same as glibc is alread doing) for storing the SP value in setjmp environment. We need to adjust for that to keep supporting setjmp/longjmp on latest Darwin. The patch is basically doing the same what we're already doing for glibc.
rdar://problem/43542596
Differential Revision: https://reviews.llvm.org/D51064
llvm-svn: 340350
Building with a new clang produces a bunch of warnings about dropped 'const' and 'volatile' qualifiers on pointers. Let's fix them.
Differential Revision: https://reviews.llvm.org/D39861
llvm-svn: 317929
On iOS/AArch64, the address space is very limited and has a dynamic maximum address based on the configuration of the device. We're already using a dynamic shadow, and we find a large-enough "gap" in the VM where we place the shadow memory. In some cases and some device configuration, we might not be able to find a large-enough gap: E.g. if the main executable is linked against a large number of libraries that are not part of the system, these libraries can fragment the address space, and this happens before ASan starts initializing.
This patch has a solution, where we have a "backup plan" when we cannot find a large-enough gap: We will restrict the address space (via MmapFixedNoAccess) to a limit, for which the shadow limit will fit.
Differential Revision: https://reviews.llvm.org/D35098
llvm-svn: 307865
The definitions in sanitizer_common may conflict with definitions from system headers because:
The runtime includes the system headers after the project headers (as per LLVM coding guidelines).
lib/sanitizer_common/sanitizer_internal_defs.h pollutes the namespace of everything defined after it, which is all/most of the sanitizer .h and .cc files and the included system headers with: using namespace __sanitizer; // NOLINT
This patch solves the problem by introducing the namespace only within the sanitizer namespaces as proposed by Dmitry.
Differential Revision: https://reviews.llvm.org/D21947
llvm-svn: 281657
Log all of sanitizers' output (not just ASan bug reports) to CrashReport,
which simplifies diagnosing failed checks as well as other errors. This
also allows to strip the color sequences early from the printed buffer,
which is more efficient than what we had perviously.
Differential Revision: http://reviews.llvm.org/D15396
llvm-svn: 256988
The Crash Report is going to add app specific info if it is stored in the magical buffer.
Differential Revision: http://reviews.llvm.org/D14791
llvm-svn: 253691
Summary:
This is one of many changes needed for compiler-rt to get it building on iOS.
This change does the following:
- Don't include crt_externs on iOS (it isn't available)
- Support ARM thread state objects
Note: this change does not enable building for iOS, as there are more changes to come.
Reviewers: glider, kubabrecka, bogner, samsonov
Reviewed By: samsonov
Subscribers: samsonov, aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D10510
llvm-svn: 240467
We recently had a broken version check because an newer OS X version is treated as MACOS_VERSION_UNKNOWN which is less than all the defined values. Let's have a separate enum value for unknown but newer versions, so the ">=" and "<=" version checks still work even in upcoming OS X releases.
Reviewed at http://reviews.llvm.org/D6137
llvm-svn: 224315
This also fixes the test/asan/TestCases/Darwin/malloc_zone-protected.cc test failure on OS X 10.10.
Reviewed at http://reviews.llvm.org/D6119
llvm-svn: 221379