This assembly is part of a macro that was reformatted in D60351.
The missing space between push and { results in:
Error: bad instruction `push{r4, r5,r6,lr}'
llvm-svn: 365957
This patch enables compiler-rt on SPARC targets. Most of the changes are straightforward:
- Add 32 and 64-bit sparc to compiler-rt
- lib/builtins/fp_lib.h needed to check if the int128_t and uint128_t types exist (which they don't on sparc)
There's one issue of note: many asan tests fail to compile on Solaris/SPARC:
fatal error: error in backend: Function "_ZN7testing8internal16BoolFromGTestEnvEPKcb": over-aligned dynamic alloca not supported.
Therefore, while asan is still built, both asan and ubsan-with-asan testing is disabled. The
goal is to check if asan keeps compiling on Solaris/SPARC. This serves asan in gcc,
which doesn't have the problem above and works just fine.
With this patch, sparcv9-sun-solaris2.11 test results are pretty good:
Failing Tests (9):
Builtins-sparc-sunos :: divtc3_test.c
Builtins-sparcv9-sunos :: compiler_rt_logbl_test.c
Builtins-sparcv9-sunos :: divtc3_test.c
[...]
UBSan-Standalone-sparc :: TestCases/TypeCheck/misaligned.cpp
UBSan-Standalone-sparcv9 :: TestCases/TypeCheck/misaligned.cpp
The builtin failures are due to Bugs 42493 and 42496. The tree contained a few additonal
patches either currently in review or about to be submitted.
Tested on sparcv9-sun-solaris2.11.
Differential Revision: https://reviews.llvm.org/D40943
llvm-svn: 365880
The MemoryMappingLayout.DumpListOfModules currently FAILs on Solaris:
[ RUN ] MemoryMappingLayout.DumpListOfModules
/vol/llvm/src/compiler-rt/local/lib/sanitizer_common/tests/sanitizer_procmaps_test.cc:52: Failure
Value of: found
Actual: false
Expected: true
[ FAILED ] MemoryMappingLayout.DumpListOfModules (22 ms)
The problem is that the test expects the executable name from modules[i].full_name(),
however the pr_mapname field of struct prmap is just the entry in /proc/<pid>/object,
which is "a.out" instead of "Sanitizer-i386-Test". Fortunately, the real name can
be determined by looking in proc/<pid>/path where "a.out" is a symlink to the
real path.
Tested on x86_64-pc-solaris2.11.
Differential Revision: https://reviews.llvm.org/D64559
llvm-svn: 365879
Summary:
There's no real reason to use clang-cl on Windows, the clang driver
works just as well. This fixes a test which uses the -O0 flag, which was
recently removed from clang-cl to match MSVC, which lacks this flag.
While I'm here, remove the explicit -std=c++11 flag. Previously, this
flag was necessary when the default C++ standard was C++98. Now that the
default is C++14, this is no longer necessary. It's problematic on
Windows, because the Visual C++ standard library relies on C++14
features, and attempting to compile it with C++11 results in errors.
Rather than adding logic to conditionally set the standard to C++11 only
on non-Win, this flag can be removed.
See http://lab.llvm.org:8011/builders/clang-x64-windows-msvc and
https://reviews.llvm.org/D64506.
Reviewers: morehouse, thakis
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D64587
llvm-svn: 365841
Summary:
A few corrections:
- rename `TransferBatch::MaxCached` to `getMaxCached` to conform with
the style guide;
- move `getBlockBegin` from `Chunk::` to `Allocator::`: I believe it
was a fallacy to have this be a `Chunk` method, as chunks'
relationship to backend blocks are up to the frontend allocator. It
makes more sense now, particularly with regard to the offset. Update
the associated chunk test as the method isn't available there
anymore;
- add a forgotten `\n` to a log string;
- for `releaseToOs`, instead of starting at `1`, start at `0` and
`continue` on `BatchClassId`: in the end it's identical but doesn't
assume a particular class id for batches;
- change a `CHECK` to a `reportOutOfMemory`: it's a clearer message
Reviewers: hctim, morehouse, eugenis, vitalybuka
Reviewed By: hctim
Subscribers: delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D64570
llvm-svn: 365816
While working on https://reviews.llvm.org/D40900 (which effectively is about enabling compiler-rt on sparc these days), I came across two failing profile testcases:
Profile-sparc :: instrprof-merge-match.test
Profile-sparc :: instrprof-merge.c
Profile-sparcv9 :: instrprof-merge-match.test
Profile-sparcv9 :: instrprof-merge.c
All of them crashed with a SIGBUS in __llvm_profile_merge_from_buffer:
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x00012368 in __llvm_profile_merge_from_buffer (
ProfileData=0x2384c <main.Buffer> "\377lprofR\201", ProfileSize=360)
at /vol/llvm/src/llvm/local/projects/compiler-rt/lib/profile/InstrProfilingMerge.c:95
95 SrcDataEnd = SrcDataStart + Header->DataSize;
where Header is insufficiently aligned for a strict-alignment target like SPARC.
Fixed by forcing the alignment to uint64_t, the members of struct __llvm_profile_header,
in the callers.
Tested on sparcv9-sun-solaris2.11.
https://reviews.llvm.org/D64498
llvm-svn: 365805
Summary:
We ran into a problem on Fuchsia where yielding threads would never
be deboosted, ultimately resulting in several threads spinning on the
same TSD, and no possibility for another thread to be scheduled,
dead-locking the process.
While this was fixed in Zircon, this lead to discussions about if
spinning without a break condition was a good decision, and settled on
a new hybrid model that would spin for a while then block.
Currently we are using a number of iterations for spinning that is
mostly arbitrary (based on sanitizer_common values), but this can
be tuned in the future.
Since we are touching `common.h`, we also use this change as a vehicle
for an Android optimization (the page size is fixed in Bionic, so use
a fixed value too).
Reviewers: morehouse, hctim, eugenis, dvyukov, vitalybuka
Reviewed By: hctim
Subscribers: srhines, delcypher, jfb, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D64358
llvm-svn: 365790
Summary:
Combine few relatively small changes into one:
- implement internal_ptrace() and internal_clone() for NetBSD
- add support for stoptheworld based on the ptrace(2) API
- define COMPILER_RT_HAS_LSAN for NetBSD
- enable tests for NetBSD/amd64
Inspired by the original implementation by Christos Zoulas in netbsd/src for GCC.
The implementation is in theory CPU independent through well defined macros
across all NetBSD ports, however only the x86_64 version was tested.
Reviewers: mgorny, dvyukov, vitalybuka, joerg, jfb
Reviewed By: vitalybuka
Subscribers: dexonsmith, jfb, srhines, kubamracek, llvm-commits, christos
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64057
llvm-svn: 365735
cl.exe doesn't understand it; there's /Od instead. See also the review
thread for r229575.
Update lots of compiler-rt tests to use -Od instead of -O0.
Ran `rg -l 'clang_cl.*O0' compiler-rt/test/ | xargs sed -i -c 's/-O0/-Od/'`
Differential Revision: https://reviews.llvm.org/D64506
llvm-svn: 365724
Fix compilation errors related to `SANITIZER_GO` `#ifdef`s.
Refine longjmp key management. For Linux, re-implement key retrieval in
C (instead of assembly). Removal of `InitializeGuardPtr` and a final
round of cleanups will be done in the next commit.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D64092
> llvm-svn: 365513
llvm-svn: 365560
A short granule is a granule of size between 1 and `TG-1` bytes. The size
of a short granule is stored at the location in shadow memory where the
granule's tag is normally stored, while the granule's actual tag is stored
in the last byte of the granule. This means that in order to verify that a
pointer tag matches a memory tag, HWASAN must check for two possibilities:
* the pointer tag is equal to the memory tag in shadow memory, or
* the shadow memory tag is actually a short granule size, the value being loaded
is in bounds of the granule and the pointer tag is equal to the last byte of
the granule.
Pointer tags between 1 to `TG-1` are possible and are as likely as any other
tag. This means that these tags in memory have two interpretations: the full
tag interpretation (where the pointer tag is between 1 and `TG-1` and the
last byte of the granule is ordinary data) and the short tag interpretation
(where the pointer tag is stored in the granule).
When HWASAN detects an error near a memory tag between 1 and `TG-1`, it
will show both the memory tag and the last byte of the granule. Currently,
it is up to the user to disambiguate the two possibilities.
Because this functionality obsoletes the right aligned heap feature of
the HWASAN memory allocator (and because we can no longer easily test
it), the feature is removed.
Also update the documentation to cover both short granule tags and
outlined checks.
Differential Revision: https://reviews.llvm.org/D63908
llvm-svn: 365551
Summary:
This way the test would better match the intended usage of the header,
plus it makes some additional testing (e.g. in CI) a bit easier to set up.
Reviewers: morehouse
Reviewed By: morehouse
Subscribers: mgorny, delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D64440
llvm-svn: 365544
Refine longjmp key management. For Linux, re-implement key retrieval in
C (instead of assembly). Removal of `InitializeGuardPtr` and a final
round of cleanups will be done in the next commit.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D64092
llvm-svn: 365513
- Adds interceptors for Rtl[Allocate|Free|Size|ReAllocate]Heap
- Adds unit tests for the new interceptors and expands HeapAlloc
tests to demonstrate new functionality.
Reviewed as D62927
- adds fixes for ~win and x64 tests
> llvm-svn: 365381
llvm-svn: 365424
- Adds interceptors for Rtl[Allocate|Free|Size|ReAllocate]Heap
- Adds unit tests for the new interceptors and expands HeapAlloc
tests to demonstrate new functionality.
Reviewed as D62927
llvm-svn: 365422
There's no point to manually create the __start___sancov_guards and __stop___sancov_guards
sections and labels on Solaris any longer. They were originally introduced in
https://reviews.llvm.org/D40899 and https://reviews.llvm.org/D40903.
- The Solaris 11.4 ld supports creating them out of the box.
- We already unconditionally use Solaris 11.4 features like the ld -z gnu-version-script-compat option and fully working .preinit_array support in compiler-rt.
- The current files don't assemble on SPARC because the assembler syntax may be different between /bin/as and GNU as.
Tested on amd64-pc-solaris2.11.
Differential Revision: https://reviews.llvm.org/D63601
llvm-svn: 365399
- Adds interceptors for Rtl[Allocate|Free|Size|ReAllocate]Heap
- Adds unit tests for the new interceptors and expands HeapAlloc
tests to demonstrate new functionality.
Reviewed as D62927
llvm-svn: 365381
A couple of UBSan-* :: TestCases/ImplicitConversion testcases FAIL on Solaris/x86
(and Solaris/SPARC with https://reviews.llvm.org/D40900):
FAIL: UBSan-AddressSanitizer-i386 :: TestCases/ImplicitConversion/signed-integer-truncation-or-sign-change-blacklist.c (49187 of 49849)
******************** TEST 'UBSan-AddressSanitizer-i386 :: TestCases/ImplicitConversion/signed-integer-truncation-or-sign-change-blacklist.c' FAILED ********************
[...]
Command Output (stderr):
--
/vol/llvm/src/compiler-rt/local/test/ubsan/TestCases/ImplicitConversion/signed-integer-truncation-or-sign-change-blacklist.c:53:11: error: CHECK: expected string not found in input
// CHECK: {{.*}}signed-integer-truncation-or-sign-change-blacklist.c:[[@LINE-1]]:10: runtime error: implicit conversion from type '{{.*}}' (aka 'unsigned int') of value 4294967295 (32-bit, unsigned) to type '{{.*}}' (aka 'signed char') changed the value to -1 (8-bit, signed)
^
<stdin>:1:1: note: scanning from here
/vol/llvm/src/compiler-rt/local/test/ubsan/TestCases/ImplicitConversion/signed-integer-truncation-or-sign-change-blacklist.c:52:10: runtime error: implicit conversion from type 'uint32_t' (aka 'unsigned int') of value 4294967295 (32-bit, unsigned) to type 'int8_t' (aka 'char') changed the value to -1 (8-bit, signed)
^
<stdin>:1:1: note: with "@LINE-1" equal to "52"
/vol/llvm/src/compiler-rt/local/test/ubsan/TestCases/ImplicitConversion/signed-integer-truncation-or-sign-change-blacklist.c:52:10: runtime error: implicit conversion from type 'uint32_t' (aka 'unsigned int') of value 4294967295 (32-bit, unsigned) to type 'int8_t' (aka 'char') changed the value to -1 (8-bit, signed)
^
<stdin>:1:69: note: possible intended match here
/vol/llvm/src/compiler-rt/local/test/ubsan/TestCases/ImplicitConversion/signed-integer-truncation-or-sign-change-blacklist.c:52:10: runtime error: implicit conversion from type 'uint32_t' (aka 'unsigned int') of value 4294967295 (32-bit, unsigned) to type 'int8_t' (aka 'char') changed the value to -1 (8-bit, signed)
^
This is always a difference for int8_t where signed char is expected, but only
char seen.
I could trace this to <sys/int_types.h> which has
/*
* Basic / Extended integer types
*
* The following defines the basic fixed-size integer types.
*
* Implementations are free to typedef them to Standard C integer types or
* extensions that they support. If an implementation does not support one
* of the particular integer data types below, then it should not define the
* typedefs and macros corresponding to that data type. Note that int8_t
* is not defined in -Xs mode on ISAs for which the ABI specifies "char"
* as an unsigned entity because there is no way to define an eight bit
* signed integral.
*/
#if defined(_CHAR_IS_SIGNED)
typedef char int8_t;
#else
#if defined(__STDC__)
typedef signed char int8_t;
#endif
#endif
_CHAR_IS_SIGNED is always defined on both sparc and x86. Since it seems ok
to have either form, I've changed the affected tests to use
'{{(signed )?}}char' instead of 'signed char'.
Tested on x86_64-pc-solaris2.11, sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.
Differential Revision: https://reviews.llvm.org/D63984
llvm-svn: 365303
Unlike asan, which isn't supported yet on 64-bit Solaris/x86, there's no reason to disable
ubsan. This patch does that, but keeps the 64-bit ubsan-with-asan tests disabled.
Tested on x86_64-pc-solaris2.11.
Differential Revision: https://reviews.llvm.org/D63982
llvm-svn: 365302
For x86_64, since we don't clobber %rsi (2nd argument) anymore, we don't
have to save/restore it.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D63946
llvm-svn: 365229
Summary:
Some clang versions (< 6.0) do not inline the atomic builtin functions
leaving unresolved references to `__atomic_load_8` and so on (seems to
be mostly 64-bit atomics on 32-bit platforms).
I tried without success to use some cmake magic to detect when that
would be the case, and decided to fall back to unconditionally
linking libatomic.
Reviewers: morehouse, eugenis, vitalybuka, hctim, tejohnson
Reviewed By: tejohnson
Subscribers: mgorny, delcypher, jfb, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D64134
llvm-svn: 365052
Summary:
In some setups, using `-fsized-deallocation` would end up not finding
a sized delete operator at link time. For now, avoid using the flag
and declare the sized delete operator in the cpp test only.
This is a tentative fix as I do not have the failing setup.
Reviewers: rnk, morehouse, hctim, eugenis, vitalybuka
Reviewed By: rnk, hctim
Subscribers: mgorny, delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D64086
llvm-svn: 365045
Summary:
Adds allocation and deallocation stack trace support to Scudo. The
default provided backtrace library for GWP-ASan is supplied by the libc
unwinder, and is suitable for production variants of Scudo. If Scudo in future
has its own unwinder, it may choose to use its own over the generic unwinder
instead.
Reviewers: cryptoad
Reviewed By: cryptoad
Subscribers: kubamracek, mgorny, #sanitizers, llvm-commits, morehouse, vlad.tsyrklevich, eugenis
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D64085
llvm-svn: 364966
Factor out `ExtractLongJmpSp` helper function and move platform-specific
code to tsan_platform_{linux,mac}.cc.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D64050
llvm-svn: 364947
Summary:
Adds two flavours of generic unwinder and all the supporting cruft. If the
supporting allocator is okay with bringing in sanitizer_common, they can use
the fast frame-pointer based unwinder from sanitizer_common. Otherwise, we also
provide the backtrace() libc-based unwinder as well. Of course, the allocator
can always specify its own unwinder and unwinder-symbolizer.
The slightly changed output format is exemplified in the first comment on this
patch. It now better incorporates backtrace information, and displays
allocation details on the second line.
Reviewers: eugenis, vlad.tsyrklevich
Reviewed By: eugenis, vlad.tsyrklevich
Subscribers: srhines, kubamracek, mgorny, cryptoad, #sanitizers, llvm-commits, morehouse
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D63841
llvm-svn: 364941
I noticed that the instance of OpenFile in sanitizer_solaris.cc is no
longer needed.
Removed as follows, tested on x86_64-pc-solaris2.11.
Differential Revision: https://reviews.llvm.org/D63764
llvm-svn: 364892
Nikita Popov