Switch from C++11 to C++14 as fuzzer requires std::chrono and stdlibc++
doesn't provide chrono literals when using -std=c++11.
Also remove 'u' from ar command to fix this warning: ar: `u' modifier
ignored since `D' is the default (see `U')
The icmp is being folded in phi only if they belong in the same BB.
This patch extends the same beyond the BB.
Have seen scenarios where this seems to be beneficial.
Differential Revision: https://reviews.llvm.org/D157740
To maintain the convention of Scudo names starting with "scudo:",
which is used by some tooling to categorize memory usage.
Reviewed By: Chia-hungDuan
Differential Revision: https://reviews.llvm.org/D157102
/data/llvm-project/compiler-rt/lib/dfsan/dfsan_custom.cpp:2546:37: error: parameter 'va_labels' set but not used [-Werror,-Wunused-but-set-parameter]
dfsan_label *va_labels, dfsan_label *ret_label,
^
1 error generated.
The atomic shared library needs to be linked against builtins. The
`add_compiler_rt_runtime` call already has `DEP builtins` but that only
ensures that the `builtins` target is built before `clang_rt.atomic` but
doesn't link against `clang_rt.builtins`, to do so we need to use
`LINK_LIBS clang_rt.builtins`.
Whilst Clang does not use these, recent GCC does, and so on systems such
as FreeBSD that wish to use compiler-rt as the system runtime library
but also wish to support building programs with GCC these interfaces are
needed.
This is a light adaptation of the code committed to GCC by Sebastian Pop
<spop@amazon.com>, relicensed with permission for use in compiler-rt.
Fixes https://github.com/llvm/llvm-project/issues/63483
Reviewed By: sebpop, MaskRay
Differential Revision: https://reviews.llvm.org/D158536
s390x is one of the architectures where the "long double" type was changed
from a 64-bit IEEE to a 128-bit IEEE type back in the glibc 2.4 days.
This means that glibc still exports two versions of the long double functions
(those that already existed back then), and we have to intercept the correct
version. There is already an existing define SANITIZER_NLDBL_VERSION that
indicates this situation, we simply have to respect it when intercepting
strtold and wcstold.
In addition, on s390x a long double return value is passed in memory via
implicit reference. This means the interceptor for functions returning
long double has to unpoison that memory slot, or else we will get
false-positive uninitialized memory reference warnings when the caller
accesses that return value - similar to what is already done in the
mallinfo interceptor. Create a variant macro INTERCEPTOR_STRTO_SRET and
use it on s390x.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D159378
This patch supports GNU ld on Solaris in addition to Solaris ld, the
default.
- Linker selection is dynamic: one can switch between Solaris ld and GNU ld
at runtime, with the default selectable with `-DCLANG_DEFAULT_LINKER`.
- Testcases have been adjusted to test both variants in case there are
differences.
- The `compiler-rt/cmake/config-ix.cmake` and
`llvm/cmake/modules/AddLLVM.cmake` changes to restrict the tests to
Solaris ld are necessary because GNU accepts unknown `-z` options, but
warns every time they are used, creating a lot of noise. Since there
seems to be no way to check for those warnings in
`llvm_check_compiler_linker_flag` or `llvm_check_compiler_linker_flag`, I
restrict the cmake tests to Solaris ld in the first place.
- The changes to `clang/test/Driver/hip-link-bundle-archive.hip` and
`flang/test/Driver/linker-flags.f90` are required when LLVM is built with
`-DCLANG_DEFAULT_LINKER=gld` on Solaris: `MSVC.cpp`
`visualstudio::Linker::ConstructJob` ultimately calls
`GetProgramPath("gld")`, resulting in a search for `gld`, which exists in
`/usr/bin/gld` on Solaris. With `-fuse-ld=`, this doesn't happen and the
expected `link` is returned.
- `compiler-rt/test/asan/TestCases/global-location-nodebug.cpp` needs to
enforce the Solaris ld, otherwise the test would `XPASS` with GNU ld
which has the `-S` semantics expected by the test.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11` with both
`-DCLANG_DEFAULT_LINKER=gld` and the default, and `x86_64-pc-linux-gnu`.
No regressions in either case.
Differential Revision: https://reviews.llvm.org/D85309
For both MSVC and MinGW targets, the compiler generates calls to
functions for probing the stack, in functions that allocate a larger
amount of stack space.
The exact behaviour of these functions differ per architecture (some
decrement the stack, some actually decrement the stack pointer,
some only probe the stack). In MSVC mode, the compiler always
generates calls to a symbol named "__chkstk". In MinGW mode, the
symbol is named "__alloca" on i386 and "___chkstk_ms" on x86_64,
but the functions behave exactly the same as their MSVC counterparts
despite the differing names.
(On i386, these names are the raw symbol names - if considering
a C level function name with the extra implicit leading underscore,
they would be called "_chkstk" and "_alloca".)
Remove the misleading duplicate and unused functions. These were
added in fbfed869106cc9c9cad7538db5e65bcd24f4d92e /
c27de5b2790b65394c50ba13fab319995dbf5956 (adding "___chkstk_ms"
for both architectures, even if that symbol name only was used
on x86_64) and 40eb83ba56ba9c1d2e6de44deacf889ac0143cf7
(adding "__alloca" and "___chkstk", even if the former only was
used on i386, and the latter seeming like a misspelled form of
the MSVC function, with three underscores instead of two).
The x86_64 "___chkstk" was doubly surprising as that function had
the same behaviour as the function used on i386, while the
"__chkstk" that MSVC emitted calls to should behave exactly like
the preexisting "___chkstk_ms".
Remove the unused functions, and rename the misspelled MSVC-like
symbols to the correct name that MSVC mode actually uses.
Note that these files aren't assembled at all when building
compiler-rt builtins in MSVC mode, as they are expected to be
provided by MSVC libraries when building code in MSVC mode.
Differential Revision: https://reviews.llvm.org/D159139
It started to fail in a flaky manner a few days ago on GreenDragon buildbots
(i.e. x86_64-darwin). I didn't track down the root cause but LSan isn't
actually supported on darwin anyway, so UNSUPPORTED seems appropriate.
Prior art: 3ff080b5.
The combined scudo allocator object is over 4MB in size which gets created via
the posix_memalign on every test run. If the tests are sanitized with asan,
then the asan allocator will need to mmap this large object every single time a
test is run. Depending on where this is mapped, we might not be able to find a
large enough contiguous space for scudo's primary allocator to reserve an arena.
Such a case is more likely to occur on 39-bit vma for RISCV where the arena size
is roughly a quarter of the whole address space and fragmentation can be a big issue.
This helps reduce fragmentation by instead placing the allocator instance in a
global storage rather than doing an anonymous mmap.
Differential Revision: https://reviews.llvm.org/D158767
When compiling the builtins with the undefined behavior sanitizer and running
testcases you end up with the following warning:
UBSan: fp_fixint_impl.inc:39:42: left shift of 8388608 by 40 places cannot be represented in type 'fixint_t' (aka 'long long')
UBSan: fp_fixint_impl.inc:39:17: signed integer overflow: -1 * -9223372036854775808 cannot be represented in type 'fixint_t' (aka 'long long')
This can be avoided by doing the shift and the multiplication in a matching
unsigned variant of the type.
The added test only trigger the intended signed overflow case when the builtins
are built with -D__SOFTFP__.
This was found in an out of tree target.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D159069
When scanning over TLS regions, we attempt to check if one of the regions is
one of the thread_local allocator caches which would be located in one of the
TLS blocks pointer to by the DTV. This is to prevent marking a pointer that was
allocated by the primary allocator (from a thread_local cache) as reachable. The
check is a simple bounds check to see if the allocator cache is within the
bounds of one of the TLS block we're iterating over, but it looks like the check
for the end of the cache is slightly incorrect.
Differential Revision: https://reviews.llvm.org/D156015
The RSS code is not very useful and can be replicated by using
ulimit. Remove it and remove the options associated with it.
Reviewed By: Chia-hungDuan
Differential Revision: https://reviews.llvm.org/D159155
stdarg.h and stddef.h have to be textual headers in their upcoming modules to support their `__needs_xxx` macros. That means that they won't get precompiled into their modules' pcm, and instead their declarations will go into every other pcm that uses them. For now that's ok since the type merger can handle the declarations in these headers, but it's suboptimal at best. Make separate headers for all of the pieces so that they can be properly modularized.
Reviewed By: aaron.ballman, ChuanqiXu
Differential Revision: https://reviews.llvm.org/D158709
Instead, make it a static array that's part of the FlagParser. The advantage
this has is helping reduce fragmentation from needing to anonymously mmap
this array via the LowLevelAllocator. This will instead place the array on
the stack. Functionally, the only difference is that the array will not be
zero-initialized, but all used elements are explicitly initialized via the
flag handlers.
Differential Revision: https://reviews.llvm.org/D158780
This reverts commit cf403c10fba72ddc6a083a0e1603974d0749c6b3.
This is breaking Android sanitizer buildbots (see the discussion on
https://reviews.llvm.org/D158793).
Invoking compiler-rt function __truncsfbf2 to convert a zero 32-bit float
0x00000000 to a 16-bit bfloat value currently generates the denormal value
0x0040, rather than value 0x0000. Negative zero 0x80000000 is converted
to denormal 0x8040 rather than 0x8000.
This behavior is seen in flang code under development (not yet integrated)
that converts bfloat/REAL(KIND=3) argument values to float/REAL(KIND=4)
values and then converts those values back to bfloat/REAL(KIND=3). There
are other instances of the problem. A round-trip type conversion using
__truncsfbf2 of a denormal generates a different denormal, and an sNaN
is converted to a qNaN.
The problem is addressed in generic conversion function fp_trunc_impl.inc
by removing trailing 0 significand bits when the source and destination
type formats are identical except for the significand size. This condition
is met only for float -> bfloat conversions.
Round-trip conversions for at least some other type pairs have the same
problem. A solution in those cases would need to account for exponent
size differences. Those cases are not relevant to flang compilations
and are not addressed here. A broader solution might subsume this fix,
or this fix might remain useful as is.
There are no existing tests of bfloat conversion functionality in the
compiler-rt test directory. Tests for other conversions use a common
infrastructure that does not currently have support for bfloat conversions.
This patch does not attempt to add that infrastructure for this new case.
CodeGen test bfloat.ll checks bfloat adds and other operations that invoke
__truncsfbf2.
SANITIZER_GLIBC is always defined so should be tested with an if not an
ifdef.
Fixes: ad7e2501000d
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D159041
The comments date back to NDK r10, which is ancient. libatomic isn't
always needed anymore, and even when it is, it's bundled into
compiler-rt in the NDK so we'll get it automatically. Remove the
unnecessary explicit links.
Reviewed By: srhines
Differential Revision: https://reviews.llvm.org/D158793
Android has only used libc++ for a long time, and since NDK r23, it
also always uses compiler-rt and LLVM's libunwind (which is linked
statically). Reflect these defaults in compiler-rt's build, instead of
requiring the correct settings to always be externally specified.
Reviewed By: srhines
Differential Revision: https://reviews.llvm.org/D158792
This removes and replaces usage of a few LowLevelAllocators with a single one
provided by sanitizer_common. Functionally, there should be no difference
between using different allocators vs the same one. This works really well
with D158783 which controls the size of each allocator mmap to significantly
reduce fragmentation.
This doesn't remove them all, mainly the ones used by asan and the flag parser.
Differential Revision: https://reviews.llvm.org/D158786
65536 bytes
The LowLevelAllocator is a helper class used by many sanitizer internals
for anonymously mmaping stuff. The allocator (usually) maps one page at
a time, but this can lead to a lot of fragmentation if the allocator is
heavily used. The flag parser is an example of this where it needs to do
lots of string copying that need to exist for a variable length of time.
This adds a macro for specifying the number of pages the LowLevelAllocator
can make at a time, which locally I've found to significantly help reduce
fragmentation and help run the scudo allocator tests in an asan-instrumented
build on riscv Sv39. This is a static macro rather than a value that could
be provided via an env variable because flag parsing is one of the earliest
consumers of the LowLevelAllocator, so this should be set before its ever used.
Note this will mainly help instances of the LowLevelAllocator that are heavily
used, but instances of the LowLevelAllocator that do a small fixed number
of allocations won't benefit as much from this. This can be alleviated though
if we instead consolidate all of them to one single LowLevelAllocator (D158786).
Differential Revision: https://reviews.llvm.org/D158783
Accessing the PLT entries of hooks can lead a certain amount of
performance overhead. This is observed on certain tasks which will do a
bunch of malloc/free and their throughputs are impacted by the null
check of hooks.
Also add SCUDO_ENABLE_HOOKS_TESTS to select if we want to run the hook
tests. On some platforms they may have different ways to run the
wrappers tests (end-to-end tests) and test the hooks along with the
wrappers tests may not be feasible. Provide an option to turn it ON/OFF.
By default, we only verify the hook behavior in the scudo standalone
tests if SCUDO_ENABLE_HOOKS is defined or COMPILER_RT_DEBUG is true.
Reviewed By: cferris, fabio-d
Differential Revision: https://reviews.llvm.org/D158784
Add config name for fuzzer lit test, to make it easier to identify failures are with which config.
Before this change, same lit tests with different configs will share the same test name.
```
********************
Failed Tests (2):
libFuzzer :: fuzzer-flags.test
libFuzzer :: fuzzer-flags.test
```
Actually this is a failure of two lit tests(two configs of the same test).
With this change, the names will be different.
```
********************
Failed Tests (2):
libFuzzer-i386-default-Linux ::fuzzer-flags.test
libFuzzer-x86_64-default-Linux :: fuzzer-flags.test
```
Reviewed By: MaskRay, vitalybuka
Differential Revision: https://reviews.llvm.org/D158696
When using debug info correlation, value profiling needs to be switched off.
So, we are only merging counter sections. In that case the existance of data
section is just used to provide an extra check in case of corrupted profile.
This patch performs counter merging by iterating the counter section by counter
size and add them together.
Reviewed By: ellis, MaskRay
Differential Revision: https://reviews.llvm.org/D157632
Fails with "The procedure entry point SetThreadDescription could not be located in the dynamic link library..."
This reverts commit cf76ddcbeb10be1f3eee5fa86dc41f9ca2435d50.
Original patch: D157632.
Fixed the issue when data is 0 by relaxing the condition.
Reviewed By: ellis
Differential Revision: https://reviews.llvm.org/D159000
Api available since Windows Server 2016/Windows 10 1607
Reviewers: vitalybuka
Reviewed-By: vitalybuka
Differential Revison: https://reviews.llvm.org/D156317
the ParseUnixMemoryProfile makes sense only on platforms which truly support procfs
Reviewers: vitalybuka
Reviewed-By: vitalybuka
Differential Revision: https://reviews.llvm.org/D156628
`strtol("0b1", 0, 0)` can be (pre-C23) 0 or (C23) 1.
`sscanf("0b10", "%i", &x)` is similar. glibc 2.38 introduced
`__isoc23_strtol` and `__isoc23_scanf` family functions for binary
compatibility.
When `_ISOC2X_SOURCE` is defined (implied by `_GNU_SOURCE`) or
`__STDC_VERSION__ > 201710L`, `__GLIBC_USE_ISOC2X` is defined to 1 and
these `__isoc23_*` symbols are used.
Add `__isoc23_` versions for the following interceptors:
* sanitizer_common_interceptors.inc implements strtoimax/strtoumax.
Remove incorrect FIXME about https://github.com/google/sanitizers/issues/321
* asan_interceptors.cpp implements just strtol and strtoll. The default
`replace_str` mode checks `nptr` is readable and `endptr` is writable.
atoi reuses the existing strtol interceptor.
* msan_interceptors.cpp implements strtol family functions and their
`_l` versions. Tested by lib/msan/tests/msan_test.cpp
* sanitizer_common_interceptors.inc implements scanf family functions.
The strtol family functions are spreaded, which is not great, but the
patch (intended for release/17.x) does not attempt to address the issue.
Add symbols to lib/sanitizer_common/symbolizer/scripts/global_symbols.txt to
support both glibc pre-2.38 and 2.38.
When build bots migrate to glibc 2.38+, we will lose test coverage for
non-isoc23 versions since the existing C++ unittests imply `_GNU_SOURCE`.
Add test/sanitizer_common/TestCases/{strtol.c,scanf.c}.
They catch msan false positive in the absence of the interceptors.
Fix https://github.com/llvm/llvm-project/issues/64388
Fix https://github.com/llvm/llvm-project/issues/64946
Link: https://lists.gnu.org/archive/html/info-gnu/2023-07/msg00010.html
("The GNU C Library version 2.38 is now available")
Reviewed By: #sanitizers, vitalybuka, mgorny
Differential Revision: https://reviews.llvm.org/D158943
The return type of `internal_strlen()` is 'uptr', but in `printf_common()` we store the result of `internal_strlen()` into an 'int' type variable.
When the result value of `internal_strlen()` is larger than the largest possible value of 'int' type, the implicit conversion from 'uptr' to 'int' will change the result value to a negative value.
Without this change, asan reports a false positive negative-size-param in the added testcase.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D157266
When the optional assignment-allocation character 'm' (Extension to the
ISO C standard) is present, we currently use internal_strlen(buf)+1 for
all of cCsS[ (D85350). Fix cCS to use the correct size.
Fix https://github.com/llvm/llvm-project/issues/61768
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D158485
