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