Due to a GCC bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25940),
GCC doesn't consider extern "C" functions with the same name but
different namespace to be the same. As such, the default visibility
attribute (on a declaration outside the namespace) doesn't get applied
to the definition in the namespace and the symbol is not exported.
This came up as an ABI diff when switching between gcc and clang for
compiling compiler-rt.
This PR separates parts of the symbolizer markup
implementation that are Fuchsia OS specific. This
is in preparation of enabling symbolizer markup
in other OSs.
GCC is able to check that the signatures of the builtins are as expected
and this shows some incorrect signatures on ld80 platforms (i.e. x86).
The *tf* functions should take 128-bit arguments but until the latest fixes
they used 80-bit long double.
Differential Revision: https://reviews.llvm.org/D153814
Normally, when __asan_option_detect_stack_use_after_return option is
set,
the instrumentation passed the adress of the shadow memory bytes to be
set, for detecting problems with local variables.
This can be a problem when the -fsanitize-stable-abi option is in
effect,
since the ABI implementation doesn't have means to communicate the
current shadow memory base address
back to its users.
This change addresses it simply by setting
__asan_shadow_memory_dynamic_address to zero. It means
that __asan_set_shadow_xx will be now called with the offset relative to
the current shadow memory
base, and the ABI implementation needs to adapt accordingly.
The other change here is to set
__asan_option_detect_stack_use_after_return to nonzer by default,
which is needed for instrumentation to take paths using the
__asan_shadow_memory_dynamic_address
and __asan_set_shadow_xx calls.
Co-authored-by: Mariusz Borsa <m_borsa@apple.com>
For an odr-violation error due to a source file linked into two DSOs, or
one DSO and the main executable, it can be difficult to identify the DSO
name. Let's print the module name in the error report.
```
echo 'extern long var; int main() { return var; }' > a.cc
echo 'long var;' > b.cc
clang++ -fpic -fsanitize=address -shared b.cc -o b.so
clang++ -fsanitize=address a.cc b.cc ./b.so -o a
```
w/o this patch:
```
==1375386==ERROR: AddressSanitizer: odr-violation (0x56067cb06240):
[1] size=8 'var' b.cc
[2] size=8 'var' b.cc
...
```
w/ this patch:
```
==1375386==ERROR: AddressSanitizer: odr-violation (0x56067cb06240):
[1] size=8 'var' b.cc in /tmp/c/a
[2] size=8 'var' b.cc in ./b.so
```
In addition, update the `report_globals=2` message to include the module
name
```
==1451005==Added Global[0x7fcfe59ae040]: beg=0x7fcfe59ae140 size=8/32 name=var source=b.cc module=./b.so dyn_init=0 odr_indicator=0x55754f939260
```
This introduces an experimental flag 'test_only_replace_dlopen_main_program'. When enabled, this will replace dlopen(main program,...) with dlopen(NULL,...), which is the correct way to get a handle to the main program.
This can be useful when ASan is statically linked, since dladdr((void*)pthread_join) or similar will return the path to the main program.
Note that dlopen(main program,...) never ends well:
- PIE in recent glibc versions (glibc bugzilla 24323), or non-PIE: return an error
- PIE in current GRTE and older glibc: attempt to load the main program again, leading to reinitializing ASan and failing to remap the shadow memory.
---------
Co-authored-by: Thurston Dang <thurston@google.com>
This updates the standalone build docs for compiler-rt to replace
deprecated LLVM_CONFIG_PATH with LLVM_CMAKE_DIR. A warning (added in
D137024) is emitted for the current instructions.
---------
Co-authored-by: Chris B <cbieneman@microsoft.com>
initCacheMaybe() will init all the size class arrays at once and it
doesn't have much work to do even if it supports partial initialization.
This avoids the call to initCacheMaybe in each allocate()/deallocate().
This adds a new helper that can be called from application code to
ensure that no mutexes are held on specific code paths. This is useful
for multiple scenarios, including ensuring no locks are held:
- at thread exit
- in peformance-critical code
- when a coroutine is suspended (can cause deadlocks)
See this discourse thread for more discussion:
https://discourse.llvm.org/t/add-threadsanitizer-check-to-prevent-coroutine-suspending-while-holding-a-lock-potential-deadlock/74051
This resubmits and fixes#69372 (was reverted because of build
breakage).
This also includes the followup change #71471 (to fix a land race).
Unclear what's going on here. I can reproduce the test failure at
https://lab.llvm.org/buildbot/#/builders/77/builds/31875 and well before
it as well.
Doesn't look like the device has changed, and I can also repro the
problem on Android 11 and Android 14. Disabling until further notice.
The new lit test fails, see comment on the PR. This also reverts
the follow-up commit, see below.
> This adds a new helper that can be called from application code to
> ensure that no mutexes are held on specific code paths. This is useful
> for multiple scenarios, including ensuring no locks are held:
>
> - at thread exit
> - in peformance-critical code
> - when a coroutine is suspended (can cause deadlocks)
>
> See this discourse thread for more discussion:
>
> https://discourse.llvm.org/t/add-threadsanitizer-check-to-prevent-coroutine-suspending-while-holding-a-lock-potential-deadlock/74051
This reverts commit bd841111f340a73eb23c1be70ff1be4c8a6afb0c.
This reverts commit 16a395b74d35c564f6f36ba4a167950a323badd9.
in https://github.com/llvm/llvm-project/pull/69625 @strega-nil added
cdecl to a huge number of sanitizer interface declarations. It looks
like she was racing against @kennyyu adding a tsan interface function. I
noticed this when merging in the latest changes from llvm/main and
corrected it.
Co-authored-by: Charlie Barto <Charles.Barto@microsoft.com>
All of the code assumes that when the pages are released, the entry is
zero'd, so use the correct function. On most systems, this does not
change anything.
This can be used to configure runtimes builds (instead of setting flags
individually), and we need to pass it down to the custom libc++ build
for it to work correctly.
Public headers intended for user code should not define `__has_feature`,
because this can break preprocessor checks done later in user code, e.g.
if they test `#ifdef __has_feature` to check for real support in the
compiler.
Replace the only use in the public header with a check for it being
supported before trying to use it. Define the fallback definition in the
internal headers, so that other internal sanitizer headers can continue
to use it as preferred.
This resolves a bug reported to GCC as https://gcc.gnu.org/PR109882
The system linker merges __objc_imageinfo flags values to select a
compatible set of flags using the minimum swift version and only
erroring on incompatible ABIs. Match that behaviour in the orc macho
platform. One wrinkle is that the JIT can add new objects after the
dylib is running code. In that case we only check for known incompatible
flags and ignore the swift version. It's too late to change the flags at
that point and swift version is unlikely to change runtime behaviour in
practice.
The Android LLVM build system builds the arm64 fuzzer lib without
HWASan, but then applications that enable HWASan can generated an object
file with a HWASan-ified version of some libc++ symbols (e.g.
`std::__1::piecewise_construct`). The linker can choose the HWASan-ified
definition, but then it cannot resolve the relocation from
libclang_rt.fuzzer-aarch64-android.a to this symbol because the high
bits of the address are unexpectedly set. This produces an error:
```
relocation R_AARCH64_ADR_PREL_PG_HI21 out of range
```
Fix this problem by linking a custom isolated libc++ into Android's
fuzzer library.
We need to pass through ANDROID_NATIVE_API_LEVEL so that the libc++ for
32-bit Android (API < 24) uses LLVM_FORCE_SMALLFILE_FOR_ANDROID.
The current TSan mappings for C/C++ on linux/x86_64 have 0.5TB
for low app mem, 1.5TB (1.17TB usable) for mid app mem and
1.5TB for high app mem.
This can get a bit cramped if the apps are huge, and/or (in the
case of mid/high app mem) with significant ASLR entropy
(default ASLR setting of 28-bits = 1TB).
This patch increases the mapping sizes to 2TB, 5TB, and 6TB for
the low, mid and high app regions respectively. This is compatible
with up to 30-bits of ASLR entropy. It is difficult to make the
mappings any larger, given the 44-bit pointer compression.
It also moves the heap region to avoid HeapEnd() overlapping with
the newly enlarged high app region.
For convenience, we now use kShadowAdd instead of kShadowXor for
this set of mappings. This should be roughly equivalent in
runtime performance.
MinGW mode can also use the MSVC/UCRT math functions. On ARM/ARM64,
mingw-w64 has always used the UCRT scalbn function. On x86, mingw-w64
recently changed to prefer the UCRT version for a large number of math
functions.
This is necessary for many projects which pass `/Gz` to their compiles,
which makes their default calling convention `__stdcall`.
(personal note, I _really_ wish there was a pragma for this)
compiler-rt/builtins doesn't depend on anything from the CRT but
currently links against it and embeds a `/defaultlib:msvcrt` in the
`.lib` file, forcing anyone linking against it to also link against that
specific CRT. This isn't necessary as the end user can just choose which
CRT they want to use independently.
