[LLVMdev] Building LLVM with asan

Sat Jan 18 13:11:10 PST 2014

For the benefit of anybody who may be finding this in the archives later,
the problem was that we're controlling what symbols are considered global
using --version-script, so the asan symbols were not considered global and
thus failed in the final link step.

On Fri, Nov 22, 2013 at 10:00 PM, Keno Fischer <kfischer at csail.mit.edu>wrote:

> 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.
>
>
> On Thu, Nov 21, 2013 at 12:26 PM, Keno Fischer <kfischer at csail.mit.edu>wrote:
>
>> Actually it only link the shlib fine. Linking any executable against it
>> fails:
>>
>> llvm[2]: Linking Release+Asserts executable llvm-lto (without symbols)
>> /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
>>  \
>>  -lLLVM-3.5svn   -lz -ltinfo -lm
>> /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
>> /usr/bin/ld: final link failed: Bad value
>>
>>
>> On Thu, Nov 21, 2013 at 12:08 PM, Keno Fischer <kfischer at csail.mit.edu>wrote:
>>
>>> 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:
>>>
>>> ifeq ($(HOST_OS), $(filter $(HOST_OS), Linux GNU GNU/kFreeBSD))
>>>     # Don't allow unresolved symbols.
>>>     LLVMLibsOptions += -Wl,--no-undefined
>>> endif
>>>
>>>
>>>
>>> On Thu, Nov 21, 2013 at 11:53 AM, Alexander Potapenko <glider at google.com
>>> > wrote:
>>>
>>>> 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.
>>>> 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.
>>>> This isn't the case on OSX where the runtime is a dynamic library and
>>>> can safely be linked to instrumented dynamic libraries.
>>>> 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:
>>>>
>>>>  "/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/
>>>> libLLVM-3.5svn.so/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 libLLVM-3.5svn.so --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
>>>>
>>>> It doesn't seem to be linking the asan runtime which seems weird since
>>>> I'm passing -faddress=sanitize.
>>>>
>>>>
>>>> On Thu, Nov 21, 2013 at 5:24 AM, Alexander Potapenko <glider at google.com
>>>> > wrote:
>>>>
>>>>> On Thu, Nov 21, 2013 at 6:18 AM, Keno Fischer <kfischer at csail.mit.edu>
>>>>> wrote:
>>>>> > Hello everybody,
>>>>> >
>>>>> > after moving from OS X to Linux build llvm with asan enabled
>>>>> Sorry, I failed to parse this. You're compiling Clang on Linux, and
>>>>> OSX is unrelated, right?
>>>>> > (I also updated
>>>>> > to trunk, but not sure if that's related). However, it's totally
>>>>> possible
>>>>> > that I missed a step that I took back when I set this up for me, so
>>>>> I might
>>>>> > be doing something very stupid. Anyway, I'm configuring LLVM with
>>>>> >
>>>>> > ../configure --prefix=/home/kfischer/julia/usr
>>>>> --build=x86_64-pc-linux-gnu
>>>>> > FC=gfortran
>>>>> >
>>>>> CC="/home/kfischer/julia/deps/llvm-svn/build_Release+Asserts/Release+Asserts/bin/clang
>>>>> > -fsanitize=address"
>>>>> >
>>>>> CXX="/home/kfischer/julia/deps/llvm-svn/build_Release+Asserts/Release+Asserts/bin/clang++"
>>>>> > -fsanitize=address --disable-profiling --enable-shared
>>>>> --enable-static
>>>>> > --enable-targets=host --disable-bindings --disable-docs
>>>>> --enable-assertions
>>>>> > --enable-optimized --disable-threads
>>>>> So you're building Clang with -fsanitize=address. Note: you won't be
>>>>> able to build libsanitizer this way.
>>>>>
>>>>> > in a different directory (build_Release+Asserts+Sanitize). As you
>>>>> can see
>>>>> > I'm bootstrapping this through a different copy of clang I just
>>>>> built.
>>>>> > However, now I'm getting tons of
>>>>> > undefined reference to `__asan_report_store8'
>>>>> > even though the command the failing command being invoked is
>>>>> >
>>>>> >
>>>>> /home/kfischer/julia/deps/llvm-svn/build_Release+Asserts/Release+Asserts/bin/clang++
>>>>> > -fsanitize=address   -O3 -Wl,-R -Wl,'$ORIGIN' -rdynamic
>>>>> >
>>>>> -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
>>>>> > -shared -o
>>>>> >
>>>>> /home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib/
>>>>> libLLVM-3.5svn.so
>>>>> > -Wl,--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
>>>>> > -Wl,--no-whole-archive -Wl,--soname,libLLVM-3.5svn.so-Wl,--no-undefined -lz
>>>>> > -ltinfo -lm
>>>>>
>>>>> Can you please add -v to the command line to see the ld invocation
>>>>> line?
>>>>> You'll need to locate the ASan runtime library and check whether it's
>>>>> a 32-bit one and if __asan_report_store8 is present in its symbol
>>>>> table.
>>>>> > Am I doing something stupid?
>>>>> > Thanks,
>>>>> > Keno
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > LLVM Developers mailing list
>>>>> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Alexander Potapenko
>>>>> Software Engineer
>>>>> Google Moscow
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140118/91808c03/attachment.html>