[cfe-dev] i386 -faddress-sanitizer

[Carsten Mattner]

On Thu, Oct 18, 2012 at 10:50 PM, Carsten Mattner
<carstenmattner at gmail.com> wrote:
> On Thu, Oct 18, 2012 at 6:27 PM, Kostya Serebryany <kcc at google.com> wrote:
>>
>>
>> On Thu, Oct 18, 2012 at 8:19 PM, Carsten Mattner <carstenmattner at gmail.com>
>> wrote:
>>>
>>> On Thu, Oct 18, 2012 at 5:41 PM, Alexander Potapenko <glider at google.com>
>>> wrote:
>>> > You have two issues here then.
>>> > First, for some reason the linker doesn't like the unresolved calls to
>>> > ASan runtime in your shared object. Can you please attach the full
>>> > command line used to invoke the linker (feel free to obfuscate the
>>> > file names if needed, but please keep the flags).
>>>
>>> clang c_src/<PROJECT>.o -lstdc++ -v -faddress-sanitizer
>>>   -shared
>>>   -L/usr/local/lib/erlang/lib/erl_interface-3.7.8/lib
>>>   -lerl_interface -lei -o priv/<PROJECT>.so
>>> clang version 3.2 (http://llvm.org/git/clang.git
>>> 278eafa2cd8296f8128d13c6466a0ace3d03a872)
>>> (http://llvm.org/git/llvm.git
>>> 2360b7ad99eedecaae512373e7be49c2143550cf)
>>> Target: i386-pc-linux-gnu
>>> Thread model: posix
>>>  "/usr/bin/ld" --eh-frame-hdr -m elf_i386 -shared -o priv/<PROJECT>.so
>>>  /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../crti.o
>>>  /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/crtbeginS.o
>>>  -L/usr/local/lib/erlang/lib/erl_interface-3.7.8/lib
>>>  -L/usr/lib/gcc/i686-pc-linux-gnu/4.7.2
>>>  -L/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../.. -L/lib -L/usr/lib
>>>  c_src/<PROJECT>.o -lstdc++
>>>  -lerl_interface -lei -lgcc --as-needed -lgcc_s
>>>  --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
>>>  /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/crtendS.o
>>>  /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../crtn.o
>>
>>
>> Hm. I don't see any reason for the failure here... Anyone?
>
> Is the probably special handling for .so files that automatically
> prevents linking in asan.a?
>
>>> > Second, you're going to have problems with unresolved symbols once you
>>> > load your shared object into a non-instrumented executable.
>>> > The only way to detect any errors in a shared library so far is to
>>> > rebuild the executable loading that library with ASan.
>>> > Please don't link libasan.a with the .so anyway, because you're likely
>>> > to have problems with the initialization order. ASan runtime needs to
>>> > be initialized at program startup.
>>>
>>> This makes sense and I'll build an instrumented Erlang runtime
>>> as a next step. With that in place do I still have to enable asan
>>> in CFLAGS when building the object file? I would say yes.
>>
>> You need to use -faddress-sanitizer while building the objects you
>> want to test. You don't need to instrument Erlang sources (but most
>> likely it won't hurt), just make sure that -faddress-sanitizer is
>> passed to the link command.
>
> That's good to know if all I want to check are faults in my
> shared object only.
>
>> BTW, we have the same problem with python.
>> In our private setting we solved it with "LD_PRELOAD=asan.so python x.py",
>> but I would not recommend this as a generally good approach.
>>
>>>
>>>
>>> Is this detail documented?
>>
>>
>> Probably no. I think we explain *how* asan works in detail, from which you
>> can deduct these limitations,
>> but that's not trivial.
>>
>>>
>>> If not maybe it should
>>
>>
>> Mmm. Perhaps.

I can confirm it basically works now with the rebuilt
Erlang runtime. Thanks everybody!

Speaking of finding errors, I never was able to find
errors in one or two projects I tried the clang static
analyzer on. Is there really nothings else to than
running the project's build wrapped with the scanner?