similar to: Sanitizers and static linking

> On 2 Sep 2016, at 11:18, Dmitry Vyukov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, Sep 1, 2016 at 2:30 PM, Kuba Brecka <kuba.brecka at gmail.com> wrote: >> Hi, >> >> I'm trying to write a TSan interceptor for the C++11 call_once function. There are currently false positive reports, because the inner __call_once function is located in

Hi, I'm trying to write a TSan interceptor for the C++11 call_once function. There are currently false positive reports, because the inner __call_once function is located in the (non-instrumented) libcxx library, and on macOS we can't expect the users to build their own instrumented libcxx. TSan already supports pthread_once and dispatch_once by having interceptors that re-implement the

> On 2 Sep 2016, at 12:11, Dmitry Vyukov <dvyukov at google.com> wrote: > > On Fri, Sep 2, 2016 at 12:09 PM, Kuba Brecka <kuba.brecka at gmail.com> wrote: >> >>> On 2 Sep 2016, at 11:18, Dmitry Vyukov via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> On Thu, Sep 1, 2016 at 2:30 PM, Kuba Brecka <kuba.brecka at gmail.com>

For the same reason we use shared runtime on OSX. We intercept libc calls by declaring a function with the same name in the sanitizer runtime library. Glibc loader puts main executable early in the symbol lookup order, which lets us interpose symbols from shared libraries with symbols from statically linked sanitizer runtime. Android (and AFAIK most other platforms) does not allow that, which is

Hello, I have been working on porting ASan to AArch64. I am building compiler-rt in "standalone mode" targeting aarch64. My build is successful, but I get the following runtime error when I run an ASan enabled executable through qemu-aarch64: ==29184==Parsed ASAN_OPTIONS: verbosity=1 ==29184==AddressSanitizer: failed to intercept '__isoc99_printf' ==29184==AddressSanitizer:

Hi, I triggered a build failure on a Windows-sanitizer by making the sanity checking in `ASAN_INTERCEPT_FUNC` a bit stricter. My best guess is that the type of the defined interceptor is not compatible (in C++ typing terms) with the “real” function. This seems to be the case for the following 2 functions: CreateThread “no conversion”: From: 'DWORD (__cdecl *)(void * ,

Hello, I am building sanitizers for our different platforms and trying to use it in an example program, but while it seems like ASAN is running it's init functions (see stdout below with ASAN_OPTIONS=verbosity=1) it never catches anything in the program. This is LLVM 8.0.1 btw. I was using this small test case: int main(int argc, char** argv) { int *array = new int[100]; delete []

Many thanks for digging into this, and sorry for my slow reply. Kamil: it sounds like your commit is involved here. Any idea what's happening? Dimitry: If we don't find anyone to debug and fix this before the release, how bad is it for FreeBSD? Can it be worked around downstream if 8.0.0 ships without a fix? Since I'm not entirely sure how supported this functionality is on FreeBSD,

Hello Alex, Thanks for the hint. It was actually not the -O flag that created the problem. But it pointed me in the right direction, when I passed -fno-experimental-new-pass-manager it started to show the error. My guess is that the new pass manager is more aggressive in removing UB? Thanks, Tobias On Mon, Feb 3, 2020 at 5:29 PM Alex Brachet-Mialot <alexbrachetmialot at gmail.com> wrote:

+eugenis@ On Sat, Sep 21, 2013 at 4:58 AM, Greg Fitzgerald <garious at gmail.com> wrote: > Why does compiler-rt ship a shared object for ASan on Android instead > of a static library? Would statically linking ASan on Android at > least be safe for standalone executables? > > And if I'm wanting to use ASan in C++ code that is invoked from an > APK, can I statically

(+correct cfe-dev list) On Tue, Jan 12, 2016 at 2:57 PM, Alexey Samsonov <vonosmas at gmail.com> wrote: > Hi Yuri, > > On Mon, Jan 11, 2016 at 9:53 AM, Yury Gribov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> UndefinedBehaviorSanitizer currently does not check for undefined >> behaviors which result from improper usage

> Static runtime will only intercept calls from the main executable, but > not from any libraries. This may work for simple standalone programs, > but you may run into puzzling failures. What type of failures do you mean? Does the symbol mismatch break assumptions in the ASan runtime? It's easy to imagine, for example, ASan missing use-after-free bugs because the call to free() is

On 01/13/2016 03:10 AM, Kostya Serebryany wrote: > FTR, here is one way to implement this in the library: > https://gcc.gnu.org/svn/gcc/branches/google/gcc-4_9/libstdc++-v3/include/bits/stl_algo.h > Search for "check sort predicate for strict weak ordering" Nice, although this wouldn't catch violations of transitivity (which is probably the most important type of bug).

On 01/13/2016 09:57 AM, Kostya Serebryany wrote: > On Tue, Jan 12, 2016 at 10:28 PM, Yury Gribov <y.gribov at samsung.com> wrote: > >> On 01/13/2016 03:10 AM, Kostya Serebryany wrote: >> >>> FTR, here is one way to implement this in the library: >>> >>> https://gcc.gnu.org/svn/gcc/branches/google/gcc-4_9/libstdc++-v3/include/bits/stl_algo.h

Hi everyone, I ran into a false positive with memory sanitizer due to it not intercepting dlinfo. I tried to get started on writing such an interceptor, but dlinfo seems like an extraordinarily difficult function to intercept. The three considerations that I would like somebody to look at are: 1) How do we get the enum values to decide what kind of pointer dlinfo is getting. Ideally we'd

Hi Alex, loading the symbols explicitly helped. With this the build process doesn't need any additional linker flags. Very nice. Thanks, Frank On 06/28/2018 04:38 PM, Alex Denisov wrote: > Hi Frank, > > If I am not mistaken it doesn't look in the whole process space by default. > Please, try loading all the symbols explicitly: > >

> Cool, can you use clang 3.3 then? :) I can, but digging deeper I see that the compiler-rt sanitizer tests depend on just-built-clang for its object instrumentation. The next time the instrumentation changes, I'd expect those tests to break. If the lit tests that require -fsanitize were moved to the clang repo, then I think it'd be safe to build compiler-rt with clang 3.3 or gcc

I have simple standalone ASan examples working on Android, and now I'd like to try using ASan with the Android build system. I'm building the release_33 branch of llvm+clang+compiler-rt with CMake. To test, I'm looking at libjpg, because with just a small change its Android.mk it compiles in a few seconds and without needing any additional dependencies. When I run 'djpeg' on

Inviting Paul to the party (he wrote the libstdc++ sort checker <https://gcc.gnu.org/svn/gcc/branches/google/gcc-4_9/libstdc++-v3/include/bits/stl_algo.h> ). On Tue, Jan 12, 2016 at 11:09 PM, Yury Gribov <y.gribov at samsung.com> wrote: > On 01/13/2016 10:08 AM, Yury Gribov wrote: > >> On 01/13/2016 09:57 AM, Kostya Serebryany wrote: >> >>> On Tue, Jan 12,

Why does compiler-rt ship a shared object for ASan on Android instead of a static library? Would statically linking ASan on Android at least be safe for standalone executables? And if I'm wanting to use ASan in C++ code that is invoked from an APK, can I statically link ASan? If not, what is the reason we need to preload Dalvik with the ASan shared object? I assume static linking here