<br><br><div class="gmail_quote">On Thu, Oct 18, 2012 at 8:19 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="im">On Thu, Oct 18, 2012 at 5:41 PM, Alexander Potapenko <<a href="mailto:glider@google.com">glider@google.com</a>> 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>
</div>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>
<div class="im">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>
</div> "/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>
<div class="im"> --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></div></blockquote><div><br></div><div>Hm. I don't see any reason for the failure here... Anyone? </div><div><br></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>
</div><div class="im">> 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>
</div>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></blockquote><div>You need to use -faddress-sanitizer while building the objects you want to test. </div><div>You don't need to instrument Erlang sources (but most likely it won't hurt), just make sure that </div>
<div>-faddress-sanitizer is passed to the link command.</div><div><br></div><div>BTW, we have the same problem with python.</div><div>In our private setting we solved it with "LD_PRELOAD=asan.so python x.py", </div>
<div>but I would not recommend this as a generally good approach. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Is this detail documented? </blockquote><div><br></div><div>Probably no. I think we explain *how* asan works in detail, from which you can deduct these limitations, </div><div>but that's not trivial. </div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If not maybe it should </blockquote><div><br></div><div>Mmm. Perhaps.</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">but I may have<br>
been not reading carefully enough.<br>
<div class="HOEnZb"><div class="h5"><br>
> On Thu, Oct 18, 2012 at 7:22 PM, Carsten Mattner<br>
> <<a href="mailto:carstenmattner@gmail.com">carstenmattner@gmail.com</a>> wrote:<br>
>> On Thu, Oct 18, 2012 at 5:18 PM, Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br>
>>><br>
>>><br>
>>> On Thu, Oct 18, 2012 at 7:00 PM, Carsten Mattner <<a href="mailto:carstenmattner@gmail.com">carstenmattner@gmail.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> On Thu, Oct 18, 2012 at 4:49 PM, Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br>
>>>> > You are linking a shared object, asan.a should not be linked to it.<br>
>>>><br>
>>>> What should happen instead?<br>
>>><br>
>>><br>
>>> nothing. asan.a should be linked only to the main executable.<br>
>><br>
>> I don't build an executable. This is a shared object which gets<br>
>> loaded at runtime. Specifically it's a .so implementing a native<br>
>> interface binding used with the Erlang runtime.<br>
>><br>
>>>> > Are these all the flags passed to ld?<br>
>>>><br>
>>>> Yes it's all minus project-specific -l and *.a and *.o args<br>
>>>> I have omitted for the email.<br>
>>><br>
>>><br>
>>> don't you have something like -Wl,-z,defs ?<br>
>>> The problem you describe was seen before in the presence of -Wl,-z,defs,<br>
>>> which forces the definitions of all symbols in .so (and __asan* symbols are<br>
>>> not defined).<br>
>>> The solution was to remove -Wl,-z,defs.<br>
>><br>
>> I can't find any of that in the verbose clang linker call's logs.<br>
>><br>
>>>> > On Thu, Oct 18, 2012 at 6:23 PM, Carsten Mattner<br>
>>>> > <<a href="mailto:carstenmattner@gmail.com">carstenmattner@gmail.com</a>><br>
>>>> > wrote:<br>
>>>> >><br>
>>>> >> On Thu, Oct 18, 2012 at 3:36 PM, Alexander Potapenko<br>
>>>> >> <<a href="mailto:glider@google.com">glider@google.com</a>><br>
>>>> >> wrote:<br>
>>>> >> > Can you append -v at the place it's being invoked to check whether<br>
>>>> >> > the<br>
>>>> >> > contents of LDFLAGS are being actually passed?<br>
>>>> >><br>
>>>> >> $ clang <INPUT_OBJECTS> -lstdc++ -v -faddress-sanitizer -shared<br>
>>>> >> <PROJECT_FLAGS> -o <SO_FILE><br>
>>>> >> clang<br>
>>>> >> 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>
>>>> >><br>
>>>> >> "/usr/bin/ld" --eh-frame-hdr -m elf_i386 -shared -o <SO_FILE><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/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>
>>>> >> <INPUT_OBJECTS> -lstdc++ -lgcc --as-needed -lgcc_s --no-as-needed -lc<br>
>>>> >> -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>
>>>> >> I guess the libasan archive should be part of the above call to ld.<br>
>>>> >><br>
>>>> >> > On Thu, Oct 18, 2012 at 5:33 PM, Carsten Mattner<br>
>>>> >> > <<a href="mailto:carstenmattner@gmail.com">carstenmattner@gmail.com</a>> wrote:<br>
>>>> >> >> On Thu, Oct 18, 2012 at 3:29 PM, Alexander Potapenko wrote:<br>
>>>> >> >>> Are you linking with ld or clang?<br>
>>>> >> >>> -faddress-sanitizer is a Clang flag, so if you're running `ld<br>
>>>> >> >>> $LDFLAGS<br>
>>>> >> >>> ...` to link your program, it won't work.<br>
>>>> >> >><br>
>>>> >> >> clang.<br>
>>>> >> >><br>
>>>> >> >>> On Thu, Oct 18, 2012 at 5:12 PM, Carsten Mattner<br>
>>>> >> >>> <<a href="mailto:carstenmattner@gmail.com">carstenmattner@gmail.com</a>> wrote:<br>
>>>> >> >>>> On Thu, Oct 18, 2012 at 12:27 AM, Eli Friedman wrote:<br>
>>>> >> >>>>> On Wed, Oct 17, 2012 at 1:43 PM, Carsten Mattner<br>
>>>> >> >>>>> <<a href="mailto:carstenmattner@gmail.com">carstenmattner@gmail.com</a>> wrote:<br>
>>>> >> >>>>>> Is it expected that -faddress-sanitizer  does not work on i386<br>
>>>> >> >>>>>> and<br>
>>>> >> >>>>>> fails<br>
>>>> >> >>>>>> to properly link resulting in errors like 'undefined symbol:<br>
>>>> >> >>>>>> __asan_init'<br>
>>>> >> >>>>>> at runtime?<br>
>>>> >> >>>>>><br>
>>>> >> >>>>>> I have ./lib/clang/3.2/lib/linux/libclang_rt.asan-i386.a in<br>
>>>> >> >>>>>> llvm's<br>
>>>> >> >>>>>> installation,<br>
>>>> >> >>>>>> but it doesn't look like it's linked automatically into the<br>
>>>> >> >>>>>> executable.<br>
>>>> >> >>>>>><br>
>>>> >> >>>>>> CFLAGS:<br>
>>>> >> >>>>>> -faddress-sanitizer -O1 -fno-omit-frame-pointer -g<br>
>>>> >> >>>>>> $PROJECT_FLAGS<br>
>>>> >> >>>>><br>
>>>> >> >>>>> You need to pass in -faddress-sanitizer both when compiling and<br>
>>>> >> >>>>> when<br>
>>>> >> >>>>> linking an application.  Try something like<br>
>>>> >> >>>>> "LDFLAGS=-faddress-sanitizer".<br>
>>>> >> >>>><br>
>>>> >> >>>> Oh that makes a lot of sense and is kind of obvious in hindsight.<br>
>>>> >> >>>> Yet it didn't work in a quick test. Any options I flags to pass<br>
>>>> >> >>>> for<br>
>>>> >> >>>> verbose printfs to see what's happening you can suggest?<br>
>>>> >> >>>> In the next test I'll also try to explicitly link the libasan<br>
>>>> >> >>>> archive<br>
>>>> >> >>>> manually for ruling out issues with that archive.<br>
>>>> >> >>>> _______________________________________________<br>
>>>> >> >>>> cfe-dev mailing list<br>
>>>> >> >>>> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
>>>> >> >>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>>>> >> >>><br>
>>>> >> >>><br>
>>>> >> >>><br>
>>>> >> >>> --<br>
>>>> >> >>> Alexander Potapenko<br>
>>>> >> >>> Software Engineer<br>
>>>> >> >>> Google Moscow<br>
>>>> >> ><br>
>>>> >> ><br>
>>>> >> ><br>
>>>> >> > --<br>
>>>> >> > Alexander Potapenko<br>
>>>> >> > Software Engineer<br>
>>>> >> > Google Moscow<br>
>>>> >> _______________________________________________<br>
>>>> >> cfe-dev mailing list<br>
>>>> >> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
>>>> >> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>>>> ><br>
>>>> ><br>
>>><br>
>>><br>
><br>
><br>
><br>
> --<br>
> Alexander Potapenko<br>
> Software Engineer<br>
> Google Moscow<br>
</div></div></blockquote></div><br>