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/20131121/17e5eed9/attachment.html>
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/20131121/ea872ca0/attachment.html>
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/20131122/2cea74c6/attachment.html>