Paolo Bonzini <pbonz...@redhat.com> writes: > On 25/01/2016 19:15, Alex Bennée wrote: >> >> Paolo Bonzini <pbonz...@redhat.com> writes: >> >>> On 25/01/2016 17:49, Alex Bennée wrote: >>>> If for example you want to use the thread sanitizer you want to ensure all >>>> binaries are linked with the library: >>>> >>>> ./configure ${TARGETS} --cc=gcc-5 --cxx=g++-5 \ >>>> --extra-cflags="-fsanitize=thread" --extra-libs="-ltsan" >>> >>> Shouldn't -fsanitize=thread work as a linker command line flag too? >> >> No, the sanitizers are compile time options as they instrument the >> generated code. It's just in the case of the ThreadSanitizer you also >> need the support library. > > That's certainly not the case. My system has at least a libubsan, > libasan and liblsan (in addition to libtsan), and "gcc -dumpspecs" > suggests that the -fsanitize options are also valid at link time: > > %{%:sanitize(address):%{!shared:libasan_preinit%O%s} > %{static-libasan:%{!shared:-Bstatic --whole-archive -lasan --no-whole-archive > -Bdynamic}}%{!static-libasan:-lasan}} > %{%:sanitize(thread):%{static-libtsan:%{!shared:-Bstatic --whole-archive > -ltsan --no-whole-archive -Bdynamic}}%{!static-libtsan:-ltsan}} > %{%:sanitize(leak):%{static-liblsan:%{!shared:-Bstatic --whole-archive > -llsan --no-whole-archive -Bdynamic}}%{!static-liblsan:-llsan}} > > (GCC specs are what they are, but you get the idea).
Hmm odd. I ran the undefined and address sanitizers without having to mess with the ldflags. I'll have a deeper dive into the docs to see whats going on. > > Paolo -- Alex Bennée