From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:39715)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <alex.bennee@linaro.org>) id 1aNzEM-00072q-FO
	for qemu-devel@nongnu.org; Tue, 26 Jan 2016 03:44:07 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <alex.bennee@linaro.org>) id 1aNzEH-0000JG-R7
	for qemu-devel@nongnu.org; Tue, 26 Jan 2016 03:44:06 -0500
Received: from mail-wm0-x235.google.com ([2a00:1450:400c:c09::235]:34475)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <alex.bennee@linaro.org>) id 1aNzEH-0000JC-Iy
	for qemu-devel@nongnu.org; Tue, 26 Jan 2016 03:44:01 -0500
Received: by mail-wm0-x235.google.com with SMTP id u188so96498064wmu.1
	for <qemu-devel@nongnu.org>; Tue, 26 Jan 2016 00:44:01 -0800 (PST)
References: <1453740558-16303-1-git-send-email-alex.bennee@linaro.org>
	<1453740558-16303-3-git-send-email-alex.bennee@linaro.org>
	<56A6625E.7070408@redhat.com> <87vb6ho79i.fsf@linaro.org>
	<56A69D4A.3060807@redhat.com>
From: Alex =?utf-8?Q?Benn=C3=A9e?= <alex.bennee@linaro.org>
In-reply-to: <56A69D4A.3060807@redhat.com>
Date: Tue, 26 Jan 2016 08:43:59 +0000
Message-ID: <87r3h4ohm8.fsf@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [Qemu-devel] [RFC PATCH 2/4] configure: introduce --extra-libs
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: mttcg@greensocs.com, peter.maydell@linaro.org, mark.burton@greensocs.com, a.rigo@virtualopensystems.com, qemu-devel@nongnu.org, fred.konrad@greensocs.com


Paolo Bonzini <pbonzini@redhat.com> writes:

> On 25/01/2016 19:15, Alex Bennée wrote:
>>
>> Paolo Bonzini <pbonzini@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