Updates GetInstructionSize to account for arm64 instruction sizes.
ARM64 instruction are always 4 bytes long but GetInstructionSize in
interception_win.cpp assumes x86_64 which has mixed sizes.
Fix is for: https://github.com/llvm/llvm-project/issues/64319
Before the changeclang_rt.asan_dynamic-aarch64.dll would crash at:
OverrideFunction -> OverrideFunctionWithHotPatch -> GetInstructionSize:825
After the change:
dllthunkintercept -> dllthunkgetrealaddressordie -> InternalGetProcAddress
Fuchsia already uses a different main function for tests, so allow
anybody to use this mechanism.
Specifically, Android has a test main that allows tests to be run
in isolation and in parallel which speeds up the unit test runs
from ~14 seconds to ~4 seconds.
Reviewed By: Chia-hungDuan
Differential Revision: https://reviews.llvm.org/D159501
This patch adds support for variadic argument for loongarch64,
which is based on MIPS64. And `check-msan` all pass.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D158587
To match other internal symbolizer functions.
This makes harder to distighush small buffer from a different failure,
but we has the same problem for the rest of the lib.
Still we use 16k buffer so it should be enough most of the time.
We can fix all function togerher if future, if needed.
Use fallback name only on the top level, in Symbolizer::Demangle or
DlAddrSymbolizer. This makes PlatformDemangle to be more consistent with
SymbolizerTool and the loop in Symbolizer::Demangle which iterates over
all availible options.
This intermediate result in moving internal symbolizer build
from sh script to CMake rules.
The flag is supposed to be used with:
-DLLVM_ENABLE_PROJECTS="clang;lld;compiler-rt" -DLLVM_ENABLE_RUNTIMES="libunwind;libcxx;libcxxabi" -Sllvm-project/llvm
After converting sh script into cmake, we may add support for other build modes.
For https://github.com/llvm/llvm-project/issues/30098
Reviewed By: kstoimenov, MaskRay
Differential Revision: https://reviews.llvm.org/D157947
This intermediate result in moving internal symbolizer build
from sh script to CMake rules.
The flag is supposed to be used with:
-DLLVM_ENABLE_PROJECTS="clang;lld;compiler-rt" -DLLVM_ENABLE_RUNTIMES="libunwind;libcxx;libcxxabi" -Sllvm-project/llvm
After converting sh script into cmake, we may add support for other build modes.
For https://github.com/llvm/llvm-project/issues/30098
Reviewed By: kstoimenov, MaskRay
Differential Revision: https://reviews.llvm.org/D157947
Instead of a linear scan, use a bitset to track rarity of features. This
improves fuzzer throughput rather dramatically (close to 2x) in early
exploratory phases; in steady state this seems to improve fuzzing
throughput by ~15% according to perf.
The benchmarks are done on an executable with ~100k features, so the
results may change based on the executable that's being fuzzed.
kFeatureSetSize is 2M so the bitset is adding 256 KB to
sizeof(InputCorpus), but this should be fine since there's already three
arrays indexed by feature index for a total of 200 MB.
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
