From: Daniele Buono <dbuono@linux.vnet.ibm.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>
Cc: Alexander Bulekov <alxndr@bu.edu>, Thomas Huth <thuth@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [PATCH v2 3/6] configure: add option to enable LTO
Date: Tue, 27 Oct 2020 10:57:14 -0400 [thread overview]
Message-ID: <756e6060-394f-fe4a-47f2-2601b6e54a45@linux.vnet.ibm.com> (raw)
In-Reply-To: <20201026155006.GE496050@redhat.com>
In terms of ar and linker, if you don't have the right mix it will just
stop at link time with an error.
In terms of using gcc the errors may be a bit more subtle, similar to
what Daniel mentioned. Succesfully compiling but then showing issues at
runtime or in the test suite.
I'm using ubuntu 18.04 and the stock compiler (based on gcc 7.5) issues
a bunch of warnings but compile succesfully with LTO.
However, the tcg binary for sparc64 is broken. System-wide emulation
stops in OpenFirmware with an exception. User emulation triggers a
segmentation fault in some of the test cases. If I compile QEMU with
--enable-debug the tests magically work.
I briefly tested with gcc-9 and that seemed to work ok, buy your mileage
may vary
On 10/26/2020 11:50 AM, Daniel P. Berrangé wrote:
> On Mon, Oct 26, 2020 at 10:51:43AM +0100, Paolo Bonzini wrote:
>> On 23/10/20 22:06, Daniele Buono wrote:
>>> This patch allows to compile QEMU with link-time optimization (LTO).
>>> Compilation with LTO is handled directly by meson. This patch adds checks
>>> in configure to make sure the toolchain supports LTO.
>>>
>>> Currently, allow LTO only with clang, since I have found a couple of issues
>>> with gcc-based LTO.
>>>
>>> In case fuzzing is enabled, automatically switch to llvm's linker (lld).
>>> The standard bfd linker has a bug where function wrapping (used by the fuzz*
>>> targets) is used in conjunction with LTO.
>>>
>>> Tested with all major versions of clang from 6 to 12
>>>
>>> Signed-off-by: Daniele Buono <dbuono@linux.vnet.ibm.com>
>>
>> What are the problems like if you have GCC or you ar/linker are not up
>> to the job? I wouldn't mind omitting the tests since this has to be
>> enabled explicitly by the user.
>
> We temporarily disabled LTO in Fedora rawhide due to GCC bugs causing
> wierd test suite asserts. Those were pre-release versions of GCC/binutils
> though. I've just tested again and LTO works correctly, so I've enabled
> LTO once again.
>
> Regards,
> Daniel
>
next prev parent reply other threads:[~2020-10-27 15:16 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-23 20:06 [PATCH v2 0/6] Add support for Control-Flow Integrity Daniele Buono
2020-10-23 20:06 ` [PATCH v2 1/6] fuzz: Make fork_fuzz.ld compatible with LLVM's LLD Daniele Buono
2020-10-23 20:06 ` [PATCH v2 2/6] configure: avoid new clang 11+ warnings Daniele Buono
2020-10-24 5:17 ` Thomas Huth
2020-10-24 12:42 ` Daniele Buono
2020-10-26 9:50 ` Paolo Bonzini
2020-10-26 15:03 ` Daniele Buono
2020-10-26 15:12 ` Paolo Bonzini
2020-10-26 21:40 ` Daniele Buono
2020-10-26 22:08 ` Peter Maydell
2020-10-27 11:26 ` Thomas Huth
2020-10-27 11:38 ` Cornelia Huck
2020-10-27 16:17 ` Daniele Buono
2020-10-23 20:06 ` [PATCH v2 3/6] configure: add option to enable LTO Daniele Buono
2020-10-26 9:51 ` Paolo Bonzini
2020-10-26 15:50 ` Daniel P. Berrangé
2020-10-27 14:57 ` Daniele Buono [this message]
2020-10-27 15:17 ` Daniel P. Berrangé
2020-10-27 20:42 ` Daniele Buono
2020-10-28 6:44 ` Paolo Bonzini
2020-10-28 18:22 ` Daniele Buono
2020-10-29 10:19 ` Paolo Bonzini
2020-10-28 9:35 ` Alex Bennée
2020-10-28 18:47 ` Daniele Buono
2020-10-23 20:06 ` [PATCH v2 4/6] cfi: Initial support for cfi-icall in QEMU Daniele Buono
2020-10-26 9:52 ` Paolo Bonzini
2020-10-27 10:11 ` Alex Bennée
2020-10-23 20:06 ` [PATCH v2 5/6] check-block: enable iotests with cfi-icall Daniele Buono
2020-10-23 20:06 ` [PATCH v2 6/6] configure: add support for Control-Flow Integrity Daniele Buono
2020-10-26 10:00 ` Paolo Bonzini
2020-10-23 20:33 ` [PATCH v2 0/6] Add " Eric Blake
2020-10-24 11:58 ` Daniele Buono
2020-10-26 9:26 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=756e6060-394f-fe4a-47f2-2601b6e54a45@linux.vnet.ibm.com \
--to=dbuono@linux.vnet.ibm.com \
--cc=alxndr@bu.edu \
--cc=berrange@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).