Address Sanitizer Link Error

Hi,

I built clang from the svn repository. It works fine, except when using

-fsanitize=address

during linking I get messages like

/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_algobase.h:372:
undefined reference to `__asan_memmove'

Anybody has an idea what I did wrong ?

Thanks
Peter

Did you checkout the llvm/project/compiler-rt project and
build/install that too?

yes. The whole build process is clean except for the warnings below (I
am on Linux/Ubuntu 13.10, x86-64). Is there any way I can explicitly
check if the necessary libraries for the address sanitizer are in
place ?

make[4]: Entering directory `/home/peter/llvm/tools/clang/runtime/compiler-rt'
warning: clang_darwin.mk: dropping arch 'i386' from lib 'eprintf' (ld
does not support it)
warning: clang_darwin.mk: dropping arch 'i386' from lib '10.4' (ld
does not support it)
warning: clang_darwin.mk: dropping arch 'x86_64' from lib '10.4' (ld
does not support it)
warning: clang_darwin.mk: dropping arch 'i386' from lib 'ios' (ld does
not support it)
warning: clang_darwin.mk: dropping arch 'x86_64' from lib 'ios' (ld
does not support it)
warning: clang_darwin.mk: dropping arch 'x86_64h' from lib 'ios' (ld
does not support it)
warning: clang_darwin.mk: dropping arch 'armv7' from lib 'ios' (ld
does not support it)
warning: clang_darwin.mk: dropping arch 'i386' from lib 'osx' (ld does
not support it)
warning: clang_darwin.mk: dropping arch 'x86_64' from lib 'osx' (ld
does not support it)
warning: clang_darwin.mk: dropping arch 'x86_64h' from lib 'osx' (ld
does not support it)
warning: clang_darwin.mk: dropping arch 'armv7' from lib 'cc_kext' (ld
does not support it)
warning: clang_darwin.mk: dropping arch 'i386' from lib 'cc_kext' (ld
does not support it)
warning: clang_darwin.mk: dropping arch 'x86_64' from lib 'cc_kext'
(ld does not support it)
warning: clang_darwin.mk: dropping arch 'x86_64h' from lib 'cc_kext'
(ld does not support it)
warning: clang_darwin.mk: dropping arch 'x86_64' from lib
'cc_kext_ios5' (ld does not support it)
warning: clang_darwin.mk: dropping arch 'x86_64h' from lib
'cc_kext_ios5' (ld does not support it)
warning: clang_darwin.mk: dropping arch 'armv7' from lib
'cc_kext_ios5' (ld does not support it)
warning: clang_darwin.mk: dropping arch 'i386' from lib 'profile_osx'
(ld does not support it)
warning: clang_darwin.mk: dropping arch 'x86_64' from lib
'profile_osx' (ld does not support it)
warning: clang_darwin.mk: dropping arch 'x86_64h' from lib
'profile_osx' (ld does not support it)
warning: clang_darwin.mk: dropping arch 'i386' from lib 'profile_ios'
(ld does not support it)
warning: clang_darwin.mk: dropping arch 'x86_64' from lib
'profile_ios' (ld does not support it)
warning: clang_darwin.mk: dropping arch 'x86_64h' from lib
'profile_ios' (ld does not support it)
warning: clang_darwin.mk: dropping arch 'armv7' from lib 'profile_ios'
(ld does not support it)
warning: clang_darwin.mk: dropping arch 'i386' from lib
'asan_osx_dynamic' (ld does not support it)
warning: clang_darwin.mk: dropping arch 'x86_64' from lib
'asan_osx_dynamic' (ld does not support it)
warning: clang_darwin.mk: dropping arch 'x86_64h' from lib
'asan_osx_dynamic' (ld does not support it)
warning: clang_darwin.mk: dropping arch 'i386' from lib 'ubsan_osx'
(ld does not support it)
warning: clang_darwin.mk: dropping arch 'x86_64' from lib 'ubsan_osx'
(ld does not support it)
warning: clang_darwin.mk: dropping arch 'x86_64h' from lib 'ubsan_osx'
(ld does not support it)

yes. The whole build process is clean except for the warnings below (I
am on Linux/Ubuntu 13.10, x86-64). Is there any way I can explicitly
check if the necessary libraries for the address sanitizer are in
place ?

You can ignore this part. It's basically build system cruft to deal
with OS X per-architecture slices.

-eric

yes. The whole build process is clean except for the warnings below (I
am on Linux/Ubuntu 13.10, x86-64). Is there any way I can explicitly
check if the necessary libraries for the address sanitizer are in
place ?

They should be installed in $PREFIX/lib/clang/3.5.0/lib/linux/

Do you invoke the linker manually, or via clang? If you use "clang
-fsanitize=address" to link, I think it should be adding the ASan
runtime to the link line automagically.

- Hans

yes, I use clang with the sanitize option to link. I have the
following libs installed

peter@peter-ThinkPad-W520:/usr/local/lib/clang/3.5.0/lib/linux$ ls
libclang_rt.asan-x86_64.a libclang_rt.lsan-x86_64.a
libclang_rt.san-x86_64.a libclang_rt.ubsan-x86_64.a
libclang_rt.dfsan-x86_64.a libclang_rt.msan-x86_64.a
libclang_rt.tsan-x86_64.a
libclang_rt.full-x86_64.a libclang_rt.profile-x86_64.a
libclang_rt.ubsan_cxx-x86_64.a

You think that should work then ?
Thanks
Peter

How do you invoke Clang? Are the sanitizer flags part of CFLAGS and CXXFLAGS?

Is this an Autools project? Sometimes you have to be creative with
Autotools projects. For example, you might need to do:

    export CC="clang -fsanitize=undefined -fsanitize=address"
    export CXX="clang -fsanitize=undefined -fsanitize=address
-fno-sanitize=vptr"

That's because there will sometimes be a link line that *omits* CFLAGS
and CXXFLAGS. For example:

    # Link using the compiler...
    $(CC) -o $(program_name) $(OBJECTS) $(LDFLAGS) $(LDLIBS)

On Mac OS X, I also find I need to set DYLD_FALLBACK_LIBRARY_PATH
before executing:

    export DYLD_FALLBACK_LIBRARY_PATH=/usr/local/lib/clang/3.4/lib/darwin/
    ./my_program

I don't recall doing similar on Linux. (But I may have done it and
forgotten about it).

Jeff

I tried the link step from the command line manually, but get the same
error messages.
In which library is __asan_memcpy expected to reside ?
Thanks
Peter

what I observe is that if I use clang (instead of clang++) for the
link step, I get a different error (undefined reference to symbol
___cxa_free_exception@@CXXABI_1.3). I thought, that clang++ is just a
synonym for clang ? How does that magic happen ?
Thanks again
Peter

here are the invocations for the linker step, with clang++ and clang.
Indeed, only in the first case -lstdc++, this seems to be derived from
the command name itself. Regarding the address sanitizer it seems that
only libclang_rt.asan-x86_64.a, which seems properly installed in the
correct path. Does anyone spot something suspicious ?

"/usr/bin/ld" -whole-archive
/usr/local/bin/../lib/clang/3.5.0/lib/linux/libclang_rt.asan-x86_64.a
-no-whole-archive -z relro --hash-style=gnu --build-id --eh-frame-hdr
-m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o
AswZSpreads /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.8/crtbegin.o
-L/home/peter/boost_1_55_0/stage/lib
-L/home/peter/quantlib/QuantLib/ql/.libs
-L/usr/local/lib/clang/3.5.0/lib/linux/
-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/usr/local/bin/../lib
-L/lib -L/usr/lib /tmp/AswZSpreads-f59282.o -lQuantLib -lpthread -lrt
-lm -ldl -export-dynamic -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/x86_64-linux-gnu/4.8/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crtn.o

"/usr/bin/ld" -whole-archive
/usr/local/bin/../lib/clang/3.5.0/lib/linux/libclang_rt.asan-x86_64.a
-no-whole-archive -z relro --hash-style=gnu --build-id --eh-frame-hdr
-m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o
AswZSpreads /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.8/crtbegin.o
-L/home/peter/boost_1_55_0/stage/lib
-L/home/peter/quantlib/QuantLib/ql/.libs
-L/usr/local/lib/clang/3.5.0/lib/linux/
-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/usr/local/bin/../lib
-L/lib -L/usr/lib /tmp/AswZSpreads-606e7c.o -lQuantLib -lpthread -lrt
-lm -ldl -export-dynamic -lgcc --as-needed -lgcc_s --no-as-needed -lc
-lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-linux-gnu/4.8/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crtn.o

oh, sorry sorry sorry. My fault. My compiler-rt svn revision was
inconsistent with the other parts of llvm. Now everything works fine.

(btw, make update does not work for me - runs forever seemingly with
no progress at all. I used to do updates manually therefore. Now I
have a script for that :slight_smile: )

thanks and sorry again for wasting your time
Peter