The author of "https://reviews.llvm.org/D92428" marked
'resize_tls_dynamic.cpp' with XFAIL for powerpc64 since
it fails on a bunch of PowerPC buildbots. However, the
original test case passes on clang-ppc64le-rhel bot. So
marking this as XFAIL makes this bot to fail as the test
case passes unexpectedly. We are marking this unsupported
on all PowerPC64 for now until it is fixed for all the
PowerPC buildbots.
The MSVC specific pragmas disable this warning, but the pragmas themselves
(when not guarded by any _MSC_VER ifdef) cause warnings for other targets,
e.g. when targeting mingw.
Instead silence the MSVC warnings about unused parameters by casting
the parameters to void.
Differential Revision: https://reviews.llvm.org/D91851
Previously, ASan would produce reports like this:
ERROR: AddressSanitizer: breakpoint on unknown address 0x000000000000 (pc 0x7fffdd7c5e86 ...)
This is unhelpful, because the developer may think this is a null
pointer dereference, and not a breakpoint exception on some PC.
The cause was that SignalContext::GetAddress would read the
ExceptionInformation array to retreive an address for any kind of
exception. That data is only available for access violation exceptions.
This changes it to be conditional on the exception type, and to use the
PC otherwise.
I added a variety of tests for common exception types:
- int div zero
- breakpoint
- ud2a / illegal instruction
- SSE misalignment
I also tightened up IsMemoryAccess and GetWriteFlag to check the
ExceptionCode rather than looking at ExceptionInformation[1] directly.
Differential Revision: https://reviews.llvm.org/D92344
Revert "[compiler-rt] [builtins] Support conversion between fp16 and fp128" & dependency
Revert "[compiler-rt] [builtins] Use _Float16 on extendhfsf2, truncdfhf2 __truncsfhf2 if available"
This reverts commit 7a94829881.
This reverts commit 1fb91fcf9c.
The include header sys/ucontext.h already defines REG_SP as 2, causing
redefinition warnings during compilation. This patch fixes that issue.
(We also can't just use the numerical definition provided by the header,
as REG_SP is used in this file this refers to a struct field.)
Differential Revision: https://reviews.llvm.org/D90934
Remove an invalid check from sizes.cpp that only passes when overcommit is disabled.
Fixes PR48274.
Differential Revision: https://reviews.llvm.org/D91999
Similar to __asan_set_error_report_callback, pass the entire report to a
user provided callback function.
Differential Revision: https://reviews.llvm.org/D91825
Also unpoison IO_write_base/_IO_write_end buffer
memcpy from fclose and fflash can copy internal bytes without metadata into user memory.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D91858
During the initial Solaris sanitizer port, I missed to enable the
`sanitizer_common` and `ubsan_minimal` testsuites. This patch fixes this,
correcting a few unportabilities:
- `Posix/getpass.cpp` failed to link since Solaris lacks `libutil`.
Omitting the library lets the test `PASS`, but I thought adding `%libutil`
along the lines of `%librt` to be overkill.
- One subtest of `Posix/getpw_getgr.cpp` is disabled because Solaris
`getpwent_r` has a different signature than expected.
- `/dev/null` is a symlink on Solaris.
- XPG7 specifies that `uname` returns a non-negative value on success.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D91606
As reported in PR 48202, two allocator tests `FAIL` on Solaris/sparcv9,
presumably because Solaris uses the full 64-bit address space and the
allocator cannot deal with that:
SanitizerCommon-Unit :: ./Sanitizer-sparcv9-Test/SanitizerCommon.CombinedAllocator32Compact
SanitizerCommon-Unit :: ./Sanitizer-sparcv9-Test/SanitizerCommon.SizeClassAllocator32Iteration
This patch disables the tests.
Tested on `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D91622
Many of the `FastUnwindTest.*` tests `FAIL` on SPARC, both Solaris and
Linux. The issue is that the fake stacks used in those tests don't match
the requirements of the SPARC unwinder in `sanitizer_stacktrace_sparc.cpp`
which has to look at the register window save area.
I'm disabling the failing tests.
Tested on `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D91618
On AArch64 it allows use the native FP16 ABI (although libcalls are
not emitted for fptrunc/fpext lowering), while on other architectures
the expected current semantic is preserved (arm for instance).
Differential Revision: https://reviews.llvm.org/D91733
This patch adds both extendhftf2 and trunctfhf2 to support
conversion between half-precision and quad-precision floating-point
values. They are enabled iff the compiler supports _Float16.
Some notes on ARM plaforms: while __fp16 is supported on all
architectures, _Float16 is supported only for 32-bit ARM, 64-bit ARM,
and SPIR (as indicated by clang/docs/LanguageExtensions.rst). Also,
__fp16 is a storage format and promoted to 'float' for argument passing
and 64-bit ARM supports floating-point convert precision to half as
base armv8-a instruction.
It means that although extendhfsf2, truncdfhf2 __truncsfhf2 will be
built for 64-bit ARM, they will be never used in practice (compiler
won't emit libcall to them). This patch does not change the ABI for
32-bit ARM, it will continue to pass _Float16 as uint16.
Differential Revision: https://reviews.llvm.org/D91732
Add a new interface __sanitizer_get_report_path which will return the
full path to the report file if __sanitizer_set_report_path was
previously called (otherwise it returns null). This is useful in
particular for memory profiling handlers to access the path which
was specified at compile time (and passed down via
__memprof_profile_filename), including the pid added to the path when
the file is opened.
There wasn't a test for __sanitizer_set_report_path, so I added one
which additionally tests the new interface.
Differential Revision: https://reviews.llvm.org/D91765
HwasanThreadList::DontNeedThread clobbers Thread::next_,
Breaking the freelist. As a result, only the top of the freelist ever
gets reused, and the rest of it is lost.
Since the Thread object with its associated ring buffer is only 8Kb, this is
typically only noticable in long running processes, such as fuzzers.
Fix the problem by switching from an intrusive linked list to a vector.
Differential Revision: https://reviews.llvm.org/D91392
Disable the test on old systems.
pthread_cond_clockwait is supported by glibc-2.30.
It also supported by Android api 30 even though we
do not run tsan on Android.
Fixes https://github.com/google/sanitizers/issues/1259
Reviewed By: dvyukov
This modifies the tests so that they can be run on Fuchsia:
- add the necessary includes for `set`/`vector` etc
- do the few modifications required to use zxtest instead og gtest
`backtrace.cpp` requires stacktrace support that Fuchsia doesn't have
yet, and `enable_disable.cpp` currently uses `fork()` which Fuchsia
doesn't support yet. I'll revisit this later.
I chose to use `harness.h` to hold my "platform-specific" include and
namespace, and using this header in tests rather than `gtest.h`,
which I am open to change if someone would rather go another direction.
Differential Revision: https://reviews.llvm.org/D91575
If the containing allocator build uses -DGWP_ASAN_DEFAULT_ENABLED=false
then the option will default to false. For e.g. Scudo, this is simpler
and more efficient than using -DSCUDO_DEFAULT_OPTIONS=... to set gwp-asan
options that have to be parsed from the string at startup.
Reviewed By: hctim
Differential Revision: https://reviews.llvm.org/D91463
CMake's find_package(Python3) and find_package(Python2) packages have a PYTHON_EXECUTABLE, Python2_EXECUTABLE, and Python3_EXECUTABLE cmake variables which control which version of python is built against. As far as I can tell, the rest of LLVM honors these variables. This can cause the build process to fail when if the automatically selected version of Python can't run due to modifications of LD_LIBRARY_PATH when using spack. The corresponding Spack issue is https://github.com/spack/spack/issues/19908. The corresponding LLVM issue is 48180
I believe an appropriate fix is to add the variables to the list of PASSTHROUGH_VARIABLES in cmake/Modules/AddCompilerRT.cmake, and this fixed compilation errors for me.
This bug affects distributions like Gentoo and package managers like Spack which allow for combinatorial versioning.
Reviewed By: Meinersbur
Differential Revision: https://reviews.llvm.org/D91536
The original code to keep track of the minimum and maximum indices
of allocated 32-bit primary regions was sketchy at best.
`MinRegionIndex` & `MaxRegionIndex` were shared between all size
classes, and could (theoretically) have been updated concurrently. This
didn't materialize anywhere I could see, but still it's not proper.
This changes those min/max indices by making them class specific rather
than global: classes are locked when growing, so there is no
concurrency there. This also allows to simplify some of the 32-bit
release code, that now doesn't have to go through all the regions to
get the proper min/max. Iterate and unmap will no longer have access to
the global min/max, but they aren't used as much so this is fine.
Differential Revision: https://reviews.llvm.org/D91106
In `GetGlobalSizeFromDescriptor` we use `dladdr` to get info on the the
current address. `dladdr` returns 0 if it failed.
During testing on Linux this returned 0 to indicate failure, and
populated the `info` structure with a NULL pointer which was
dereferenced later.
This patch checks for `dladdr` returning 0, and in that case returns 0
from `GetGlobalSizeFromDescriptor` to indicate failure of identifying
the address.
This occurs when `GetModuleNameAndOffsetForPC` succeeds for some address
not in a dynamically loaded library. One example is when the found
"module" is '[stack]' having come from parsing /proc/self/maps.
Differential Revision: https://reviews.llvm.org/D91344
This unit test code was using malloc without a corresponding free.
When the system malloc is not being overridden by the code under
test, it might an asan/lsan allocator that notices leaks.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D91472
Adds a new option, `handle_winexcept` to try to intercept uncaught
Visual C++ exceptions on Windows. On Linux, such exceptions are handled
implicitly by `std::terminate()` raising `SIBABRT`. This option brings the
Windows behavior in line with Linux.
Unfortunately this exception code is intentionally undocumented, however
has remained stable for the last decade. More information can be found
here: https://devblogs.microsoft.com/oldnewthing/20100730-00/?p=13273
Reviewed By: morehouse, metzman
Differential Revision: https://reviews.llvm.org/D89755
This patch enables building compiler-rt builtins for ARM targets that
only support single-precision floating point instructions (e.g., those
with -mfpu=fpv4-sp-d16).
This fixes PR42838
Differential Revision: https://reviews.llvm.org/D90698
Vitaly Buka