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 why we need to LD_PRELOAD interceptors.
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. I would be very surprised if
it worked for any JNI code.
On Sat, Sep 21, 2013 at 9:45 AM, Kostya Serebryany <kcc at google.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 link ASan? If not, what is the reason we need
>> to preload Dalvik with the ASan shared object? I assume static
>> linking here would mean that ASan would miss leaks and overflows in
>> Dalvik, but are there other drawbacks?
>>
>> Thanks,
>> Greg
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>