[cfe-dev] i386 -faddress-sanitizer

[Carsten Mattner]

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.