<br><br><div class="gmail_quote">On Sat, Oct 20, 2012 at 3:15 PM, 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 Fri, Oct 19, 2012 at 9:07 AM, Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br>
><br>
><br>
> On Fri, Oct 19, 2012 at 12:50 AM, Carsten Mattner <<a href="mailto:carstenmattner@gmail.com">carstenmattner@gmail.com</a>><br>
> wrote:<br>
>><br>
>> 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<br>
>> > <<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<br>
>> >> <<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<br>
>> >> > 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>
>> Is the probably special handling for .so files that automatically<br>
>> prevents linking in asan.a?<br>
><br>
><br>
><br>
> In the clang driver we check what is being linked and pass libasan.a to ld<br>
> only if the final executable is being linked.<br>
> So, a shared library just doesn't get linked with asan.a, but it still has<br>
> __asan_report_* callbacks,<br>
> which may cause link errors if you are using -Wl,-z,defs (or something<br>
> similar).<br>
> Looks like you have resolved the problem, right?<br>
<br>
</div></div>Yes after being told which parts need to be built with or without<br>
-faddress-sanitizer it was simple to use.<br>
<div class="im"><br>
> Let us know if the tool works for your case (and if you find bugs in Erlang<br>
> :)<br>
<br>
</div>Is runtime abort upon detecting an error the expected effect?<br></blockquote><div><br></div><div>Yes, asan exits on the first error, this is by design. </div><div>(hm, I guess we need to make a FAQ entry about this... Will do.) </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Anything else?<br>
<div class="im"><br>
> BTW, I've extended the docs a bit:<br>
> <a href="http://clang.llvm.org/docs/AddressSanitizer.html#usage" target="_blank">http://clang.llvm.org/docs/AddressSanitizer.html#usage</a><br>
<br>
</div>Thanks. I believe you should explicity document that LDFLAGS<br>
when building a shared object should not contain -faddress-sanitizer<br></blockquote><div><br></div><div>LDFLAGS may contain  -faddress-sanitizer when building DSOs -- it won't hurt but it will be ignored. </div><div>
<br></div><div>--kcc </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
because it's not how it's meant to be used - as I found out.<br>
<div class="HOEnZb"><div class="h5"><br>
> --kcc<br>
><br>
>><br>
>><br>
>> >> > Second, you're going to have problems with unresolved symbols once<br>
>> >> > 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<br>
>> >> > 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>
>> That's good to know if all I want to check are faults in my<br>
>> shared object only.<br>
>><br>
>> > BTW, we have the same problem with python.<br>
>> > In our private setting we solved it with "LD_PRELOAD=asan.so python<br>
>> > 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<br>
>> > 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>
><br>
><br>
</div></div></blockquote></div><br>