<div dir="ltr">Alright, this somehow started to work after I blew away both the bootstrapped and the instrumented version using the above removing the above lines from tools/llvm-shlib/Makefile. Does anybody know why they are there in the first place? Nothing seemed broken after removing them.</div>

<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 21, 2013 at 12:26 PM, Keno Fischer <span dir="ltr"><<a href="mailto:kfischer@csail.mit.edu" target="_blank">kfischer@csail.mit.edu</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Actually it only link the shlib fine. Linking any executable against it fails:<div><br></div><div><div>
llvm[2]: Linking Release+Asserts executable llvm-lto (without symbols)</div>
<div>/home/kfischer/julia/deps/llvm-svn/build_Release+Asserts/Release+Asserts/bin/clang++ -fsanitize=address -O3 -Wl,-R -Wl,'$ORIGIN/../lib' -L/home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib -L/home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib -Wl,--version-script=/home/kfischer/julia/deps/llvm-svn/autoconf/ExportMap.map -fsanitize=address   -o /home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/bin/llvm-lto  /home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/tools/llvm-lto/Release+Asserts/llvm-lto.o  \</div>


<div><span style="white-space:pre-wrap">  </span>-lLLVM-3.5svn   -lz -ltinfo -lm</div><div>/usr/bin/ld: /home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/bin/llvm-lto: local symbol `__asan_report_store4' in /home/kfischer/julia/deps/llvm-svn/build_Release+Asserts/Release+Asserts/bin/../lib/clang/3.5/lib/linux/libclang_rt.asan-x86_64.a(asan_rtl.o) is referenced by DSO</div>


<div>/usr/bin/ld: final link failed: Bad value</div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 21, 2013 at 12:08 PM, Keno Fischer <span dir="ltr"><<a href="mailto:kfischer@csail.mit.edu" target="_blank">kfischer@csail.mit.edu</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Indeed, removing that flag works fine, the only question is why this is added in tools/llvm-shlib/Makefile in the first place then and what to do about it:<div>


<br></div><div><div>ifeq ($(HOST_OS), $(filter $(HOST_OS), Linux GNU GNU/kFreeBSD))</div>
<div>    # Don't allow unresolved symbols.</div><div>    LLVMLibsOptions += -Wl,--no-undefined</div><div>endif</div></div><div><br></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Nov 21, 2013 at 11:53 AM, Alexander Potapenko <span dir="ltr"><<a href="mailto:glider@google.com" target="_blank">glider@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Yeah, it's not linking the runtime because you're building a shared library. This is totally ok. In this case there are undefined __asan_* symbols that are resolved when an instrumented binary loads your library.<br>





What's wrong here is that some flag passed to ld prevents it from creating undefined symbols (--no-undefined?). This flag must be removed when building with ASan.<br>
This isn't the case on OSX where the runtime is a dynamic library and can safely be linked to instrumented dynamic libraries.</p><div><div>
<div style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">What I meant to say was that it worked for me on OS X on a slightly older version of LLVM. Anyway, here's the ld line: <div>
<br></div><div> "/usr/bin/ld" -export-dynamic -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -shared -o /home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib/<a href="http://libLLVM-3.5svn.so" target="_blank">libLLVM-3.5svn.so</a> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbeginS.o -L/home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib -L/home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib -L/usr/lib/gcc/x86_64-linux-gnu/4.8 -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../.. -L/lib -L/usr/lib -R "\$ORIGIN" --whole-archive -lLLVMAnalysis -lLLVMAsmParser -lLLVMAsmPrinter -lLLVMBitReader -lLLVMBitWriter -lLLVMCodeGen -lLLVMCore -lLLVMDebugInfo -lLLVMExecutionEngine -lLLVMInstCombine -lLLVMInstrumentation -lLLVMInterpreter -lLLVMipa -lLLVMipo -lLLVMIRReader -lLLVMLinker -lLLVMLTO -lLLVMMC -lLLVMMCDisassembler -lLLVMMCJIT -lLLVMMCParser -lLLVMObjCARCOpts -lLLVMObject -lLLVMOption -lLLVMRuntimeDyld -lLLVMScalarOpts -lLLVMSelectionDAG -lLLVMSupport -lLLVMTarget -lLLVMTransformUtils -lLLVMVectorize -lLLVMX86AsmParser -lLLVMX86AsmPrinter -lLLVMX86CodeGen -lLLVMX86Desc -lLLVMX86Disassembler -lLLVMX86Info -lLLVMX86Utils --no-whole-archive --soname <a href="http://libLLVM-3.5svn.so" target="_blank">libLLVM-3.5svn.so</a> --no-undefined -lz -ltinfo -lm -lstdc++ -lm -lgcc_s -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/4.8/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crtn.o<br>






</div><div><br></div><div>It doesn't seem to be linking the asan runtime which seems weird since I'm passing -faddress=sanitize.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 21, 2013 at 5:24 AM, Alexander Potapenko <span dir="ltr"><<a href="mailto:glider@google.com" target="_blank">glider@google.com</a>></span> wrote:<br>






<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Thu, Nov 21, 2013 at 6:18 AM, Keno Fischer <<a href="mailto:kfischer@csail.mit.edu" target="_blank">kfischer@csail.mit.edu</a>> wrote:<br>







> Hello everybody,<br>
><br>
> after moving from OS X to Linux build llvm with asan enabled<br>
</div>Sorry, I failed to parse this. You're compiling Clang on Linux, and<br>
OSX is unrelated, right?<br>
<div>> (I also updated<br>
> to trunk, but not sure if that's related). However, it's totally possible<br>
> that I missed a step that I took back when I set this up for me, so I might<br>
> be doing something very stupid. Anyway, I'm configuring LLVM with<br>
><br>
> ../configure --prefix=/home/kfischer/julia/usr --build=x86_64-pc-linux-gnu<br>
> FC=gfortran<br>
> CC="/home/kfischer/julia/deps/llvm-svn/build_Release+Asserts/Release+Asserts/bin/clang<br>
> -fsanitize=address"<br>
> CXX="/home/kfischer/julia/deps/llvm-svn/build_Release+Asserts/Release+Asserts/bin/clang++"<br>
> -fsanitize=address --disable-profiling --enable-shared --enable-static<br>
> --enable-targets=host --disable-bindings --disable-docs --enable-assertions<br>
> --enable-optimized --disable-threads<br>
</div>So you're building Clang with -fsanitize=address. Note: you won't be<br>
able to build libsanitizer this way.<br>
<div><br>
> in a different directory (build_Release+Asserts+Sanitize). As you can see<br>
> I'm bootstrapping this through a different copy of clang I just built.<br>
> However, now I'm getting tons of<br>
> undefined reference to `__asan_report_store8'<br>
> even though the command the failing command being invoked is<br>
><br>
> /home/kfischer/julia/deps/llvm-svn/build_Release+Asserts/Release+Asserts/bin/clang++<br>
> -fsanitize=address   -O3 -Wl,-R -Wl,'$ORIGIN' -rdynamic<br>
> -L/home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib<br>
> -L/home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib<br>
> -shared -o<br>
> /home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib/<a href="http://libLLVM-3.5svn.so" target="_blank">libLLVM-3.5svn.so</a><br>
> -Wl,--whole-archive -lLLVMAnalysis -lLLVMAsmParser -lLLVMAsmPrinter<br>
> -lLLVMBitReader -lLLVMBitWriter -lLLVMCodeGen -lLLVMCore -lLLVMDebugInfo<br>
> -lLLVMExecutionEngine -lLLVMInstCombine -lLLVMInstrumentation<br>
> -lLLVMInterpreter -lLLVMipa -lLLVMipo -lLLVMIRReader -lLLVMLinker -lLLVMLTO<br>
> -lLLVMMC -lLLVMMCDisassembler -lLLVMMCJIT -lLLVMMCParser -lLLVMObjCARCOpts<br>
> -lLLVMObject -lLLVMOption -lLLVMRuntimeDyld -lLLVMScalarOpts<br>
> -lLLVMSelectionDAG -lLLVMSupport -lLLVMTarget -lLLVMTransformUtils<br>
> -lLLVMVectorize -lLLVMX86AsmParser -lLLVMX86AsmPrinter -lLLVMX86CodeGen<br>
> -lLLVMX86Desc -lLLVMX86Disassembler -lLLVMX86Info -lLLVMX86Utils<br>
> -Wl,--no-whole-archive -Wl,--soname,<a href="http://libLLVM-3.5svn.so" target="_blank">libLLVM-3.5svn.so</a> -Wl,--no-undefined -lz<br>
> -ltinfo -lm<br>
<br>
</div>Can you please add -v to the command line to see the ld invocation line?<br>
You'll need to locate the ASan runtime library and check whether it's<br>
a 32-bit one and if __asan_report_store8 is present in its symbol<br>
table.<br>
<div>> Am I doing something stupid?<br>
> Thanks,<br>
> Keno<br>
><br>
><br>
</div>> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
<span><font color="#888888"><br>
<br>
<br>
--<br>
Alexander Potapenko<br>
Software Engineer<br>
Google Moscow<br>
</font></span></blockquote></div><br></div>
</div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>