meson.build | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
The large comment in the patch says it all; the -no-pie flag is broken and
this is why it was not included in QEMU_LDFLAGS before commit a988b4c5614
("build: move remaining compiler flag tests to meson", 2023-05-18).
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1664
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
meson.build | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/meson.build b/meson.build
index 0a5cdefd4d3d..6733b2917081 100644
--- a/meson.build
+++ b/meson.build
@@ -267,10 +267,15 @@ endif
# has explicitly disabled PIE we need to extend our cflags.
if not get_option('b_pie')
qemu_common_flags += cc.get_supported_arguments('-fno-pie')
- if not get_option('prefer_static')
- # No PIE is implied by -static which we added above.
- qemu_ldflags += cc.get_supported_link_arguments('-no-pie')
- endif
+ # What about linker flags? For a static build, no PIE is implied by -static
+ # which we added above. For dynamic linking, adding -no-pie is messy because
+ # it overrides -shared: the linker then wants to build an executable instead
+ # of a shared library and the build fails. Before moving this code to Meson,
+ # we went through a dozen different commits affecting the usage of -no-pie,
+ # ultimately settling for a completely broken one that added -no-pie to the
+ # compiler flags together with -fno-pie... except that -no-pie is a linker
+ # flag that has no effect on the compiler command line. So, don't add
+ # -no-pie anywhere and cross fingers.
endif
if not get_option('stack_protector').disabled()
--
2.40.1On Mon, May 22, 2023 at 10:08:16AM +0200, Paolo Bonzini wrote:
> The large comment in the patch says it all; the -no-pie flag is broken and
> this is why it was not included in QEMU_LDFLAGS before commit a988b4c5614
> ("build: move remaining compiler flag tests to meson", 2023-05-18).
>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1664
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> meson.build | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index 0a5cdefd4d3d..6733b2917081 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -267,10 +267,15 @@ endif
> # has explicitly disabled PIE we need to extend our cflags.
> if not get_option('b_pie')
> qemu_common_flags += cc.get_supported_arguments('-fno-pie')
> - if not get_option('prefer_static')
> - # No PIE is implied by -static which we added above.
> - qemu_ldflags += cc.get_supported_link_arguments('-no-pie')
> - endif
> + # What about linker flags? For a static build, no PIE is implied by -static
> + # which we added above. For dynamic linking, adding -no-pie is messy because
> + # it overrides -shared: the linker then wants to build an executable instead
> + # of a shared library and the build fails. Before moving this code to Meson,
> + # we went through a dozen different commits affecting the usage of -no-pie,
> + # ultimately settling for a completely broken one that added -no-pie to the
> + # compiler flags together with -fno-pie... except that -no-pie is a linker
> + # flag that has no effect on the compiler command line. So, don't add
> + # -no-pie anywhere and cross fingers.
> endif
I'm curious why we need to do anything ? I would have thought that meson
should handle 'b_pie' itself, passing the right args to $CC that it feels
are appropriate. I don't recall seeing other apps using meson trying to
handle b_pie logic - what's special about QEMU ? IOW, is it possible to
delete this entire b_pie condition and thus avoid worrying about this
problem ?
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, May 23, 2023 at 10:00 AM Daniel P. Berrangé <berrange@redhat.com> wrote: > I'm curious why we need to do anything ? I would have thought that meson > should handle 'b_pie' itself, passing the right args to $CC that it feels > are appropriate. I don't recall seeing other apps using meson trying to > handle b_pie logic - what's special about QEMU ? IOW, is it possible to > delete this entire b_pie condition and thus avoid worrying about this > problem ? The issue is that Meson only has "enable PIE" or "leave PIE to the compiler default", while QEMU also has "disable PIE"---which is the messy one. Paolo
On Tue, May 23, 2023 at 10:02:51AM +0200, Paolo Bonzini wrote: > On Tue, May 23, 2023 at 10:00 AM Daniel P. Berrangé <berrange@redhat.com> wrote: > > I'm curious why we need to do anything ? I would have thought that meson > > should handle 'b_pie' itself, passing the right args to $CC that it feels > > are appropriate. I don't recall seeing other apps using meson trying to > > handle b_pie logic - what's special about QEMU ? IOW, is it possible to > > delete this entire b_pie condition and thus avoid worrying about this > > problem ? > > The issue is that Meson only has "enable PIE" or "leave PIE to the > compiler default", while QEMU also has "disable PIE"---which is the > messy one. Does QEMU actually need "disable PIE" ? It existed in configure of course, is there a reason we need to continue to support it in meson ? With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 5/23/23 01:18, Daniel P. Berrangé wrote: > On Tue, May 23, 2023 at 10:02:51AM +0200, Paolo Bonzini wrote: >> On Tue, May 23, 2023 at 10:00 AM Daniel P. Berrangé <berrange@redhat.com> wrote: >>> I'm curious why we need to do anything ? I would have thought that meson >>> should handle 'b_pie' itself, passing the right args to $CC that it feels >>> are appropriate. I don't recall seeing other apps using meson trying to >>> handle b_pie logic - what's special about QEMU ? IOW, is it possible to >>> delete this entire b_pie condition and thus avoid worrying about this >>> problem ? >> >> The issue is that Meson only has "enable PIE" or "leave PIE to the >> compiler default", while QEMU also has "disable PIE"---which is the >> messy one. > > Does QEMU actually need "disable PIE" ? It existed in configure of > course, is there a reason we need to continue to support it in meson ? We need it for aarch64 runner, because the OS built glibc static libraries with -fpie instead of -fPIE, and we get a relocation overflow at link time. Upstream glibc has been fixed, but there has been no update to ubuntu packages. r~
On Tue, May 23, 2023 at 10:18 AM Daniel P. Berrangé <berrange@redhat.com> wrote: > > The issue is that Meson only has "enable PIE" or "leave PIE to the > > compiler default", while QEMU also has "disable PIE"---which is the > > messy one. > > Does QEMU actually need "disable PIE" ? It existed in configure of > course, is there a reason we need to continue to support it in meson ? We have "disable PIE" support because PIE has a performance cost, though that's mostly for 32-bit x86 processors. Other ISAs have instructions that help (like x86-64's RIP-relative addressing, aarch64's adr/adrp, or RISC-V's auipc) and then position-independent code becomes the natural one anyway. However, I am inclined to keep it also because "--disable-pie uses the compiler default, and who knows what your distro did" is less obvious than "--disable-pie disables PIE". Paolo
Am 22.05.23 um 10:08 schrieb Paolo Bonzini:
> The large comment in the patch says it all; the -no-pie flag is broken and
> this is why it was not included in QEMU_LDFLAGS before commit a988b4c5614
> ("build: move remaining compiler flag tests to meson", 2023-05-18).
>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1664
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> meson.build | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index 0a5cdefd4d3d..6733b2917081 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -267,10 +267,15 @@ endif
> # has explicitly disabled PIE we need to extend our cflags.
> if not get_option('b_pie')
> qemu_common_flags += cc.get_supported_arguments('-fno-pie')
> - if not get_option('prefer_static')
> - # No PIE is implied by -static which we added above.
> - qemu_ldflags += cc.get_supported_link_arguments('-no-pie')
> - endif
> + # What about linker flags? For a static build, no PIE is implied by -static
> + # which we added above. For dynamic linking, adding -no-pie is messy because
> + # it overrides -shared: the linker then wants to build an executable instead
> + # of a shared library and the build fails. Before moving this code to Meson,
> + # we went through a dozen different commits affecting the usage of -no-pie,
> + # ultimately settling for a completely broken one that added -no-pie to the
> + # compiler flags together with -fno-pie... except that -no-pie is a linker
> + # flag that has no effect on the compiler command line. So, don't add
> + # -no-pie anywhere and cross fingers.
> endif
>
> if not get_option('stack_protector').disabled()
QEMU builds again on Windows with MSYS2 mingw64.
I also tried to build QEMU on Windows with libslirp from the subproject
folder. The issue reported in
https://gitlab.com/qemu-project/qemu/-/issues/1664 is fixed, but it now
fails with a different error. This is a libslirp bug. See
https://gitlab.freedesktop.org/slirp/libslirp/-/issues/68. The revision
in subprojects/slirp.wrap should be at least
fc5eaaf6f68d5cff76468c63984c33c4fb51506d.
Building QEMU on my Linux system works fine.
Tested-by: Volker Rümelin <vr_qemu@t-online.de>
On 5/22/23 01:08, Paolo Bonzini wrote:
> The large comment in the patch says it all; the -no-pie flag is broken and
> this is why it was not included in QEMU_LDFLAGS before commit a988b4c5614
> ("build: move remaining compiler flag tests to meson", 2023-05-18).
It's not nearly as simple as that.
> + # What about linker flags? For a static build, no PIE is implied by -static
> + # which we added above. For dynamic linking, adding -no-pie is messy because
> + # it overrides -shared: the linker then wants to build an executable instead
> + # of a shared library and the build fails. Before moving this code to Meson,
> + # we went through a dozen different commits affecting the usage of -no-pie,
> + # ultimately settling for a completely broken one that added -no-pie to the
> + # compiler flags together with -fno-pie... except that -no-pie is a linker
> + # flag that has no effect on the compiler command line.
-no-pie is a linker flag, but distro folk that didn't quite know what they were doing made
local changes to gcc's specs file. So it *is* a compiler command-line flag, but only for
some builds of gcc.
We can't just remove -no-pie, we need to probe for it as cc.get_supported_arguments
instead of cc.get_supported_link_arguments.
Or something. It's a mess, for sure.
r~
22.05.2023 18:54, Richard Henderson wrote: .. > -no-pie is a linker flag, but distro folk that didn't quite know what they were doing made local changes to gcc's specs file. So it *is* a compiler > command-line flag, but only for some builds of gcc. Which distros is that? Debian? Patching gcc spec file like this - if that's true - is a way to disaster, and should be stopped. Thanks, /mjt > We can't just remove -no-pie, we need to probe for it as cc.get_supported_arguments instead of cc.get_supported_link_arguments. > > Or something. It's a mess, for sure. > > > r~ > >
On 5/22/23 01:08, Paolo Bonzini wrote:
> The large comment in the patch says it all; the -no-pie flag is broken and
> this is why it was not included in QEMU_LDFLAGS before commit a988b4c5614
> ("build: move remaining compiler flag tests to meson", 2023-05-18).
>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1664
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> meson.build | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index 0a5cdefd4d3d..6733b2917081 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -267,10 +267,15 @@ endif
> # has explicitly disabled PIE we need to extend our cflags.
> if not get_option('b_pie')
> qemu_common_flags += cc.get_supported_arguments('-fno-pie')
> - if not get_option('prefer_static')
> - # No PIE is implied by -static which we added above.
> - qemu_ldflags += cc.get_supported_link_arguments('-no-pie')
> - endif
> + # What about linker flags? For a static build, no PIE is implied by -static
> + # which we added above.
Is it though? That was the major problem at the time: it wasn't.
IIRC, debian has enabled link-pie-by-default, so '-static' meant '-static-pie'. Moreover,
not all of their static libraries were built -fpie, which led to link errors.
Trying both now, e.g. '--static --disable-system --disable-tools --disable-docs',
a link line contains
... -Wl,--as-needed -Wl,--no-undefined -pie -Wl,--whole-archive libhwcore.fa ...
^^^^
Where does that come from, and why isn't -no-pie the antidote?
r~
On Mon, May 22, 2023 at 4:39 PM Richard Henderson
<richard.henderson@linaro.org> wrote:
> > + # What about linker flags? For a static build, no PIE is implied by -static
> > + # which we added above.
>
> Is it though? That was the major problem at the time: it wasn't.
It's what configure was doing:
if test "$static" = "yes"; then
if test "$pie" != "no" && compile_prog "-Werror -fPIE -DPIE"
"-static-pie"; then
CONFIGURE_CFLAGS="-fPIE -DPIE $CONFIGURE_CFLAGS"
pie="yes"
elif test "$pie" = "yes"; then
error_exit "-static-pie not available due to missing toolchain support"
else
pie="no"
QEMU_CFLAGS="-fno-pie $QEMU_CFLAGS"
fi
elif test "$pie" = "no"; then
if compile_prog "-Werror -fno-pie" "-no-pie"; then
CONFIGURE_CFLAGS="-fno-pie $CONFIGURE_CFLAGS"
CONFIGURE_LDFLAGS="-no-pie $CONFIGURE_LDFLAGS"
QEMU_CFLAGS="-fno-pie -no-pie $QEMU_CFLAGS"
fi
fi
Note that the code to use -no-pie is only used if test "$static" = no.
> Trying both now, e.g. '--static --disable-system --disable-tools --disable-docs',
> a link line contains
>
> ... -Wl,--as-needed -Wl,--no-undefined -pie -Wl,--whole-archive libhwcore.fa ...
> ^^^^
>
> Where does that come from, and why isn't -no-pie the antidote?
That comes from Meson's -Db_pie=true, but it is followed by
-static-pie later in the command line so all is good.
In other words, whatever we add second in the command line wins and
that is good for executables; but it is a problem when -no-pie
overrides -shared, thus messing up compilation of any shared library.
Paolo
On 22/5/23 10:08, Paolo Bonzini wrote:
> The large comment in the patch says it all; the -no-pie flag is broken and
> this is why it was not included in QEMU_LDFLAGS before commit a988b4c5614
> ("build: move remaining compiler flag tests to meson", 2023-05-18).
>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1664
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> meson.build | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index 0a5cdefd4d3d..6733b2917081 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -267,10 +267,15 @@ endif
> # has explicitly disabled PIE we need to extend our cflags.
> if not get_option('b_pie')
> qemu_common_flags += cc.get_supported_arguments('-fno-pie')
> - if not get_option('prefer_static')
> - # No PIE is implied by -static which we added above.
> - qemu_ldflags += cc.get_supported_link_arguments('-no-pie')
> - endif
> + # What about linker flags? For a static build, no PIE is implied by -static
> + # which we added above. For dynamic linking, adding -no-pie is messy because
> + # it overrides -shared: the linker then wants to build an executable instead
> + # of a shared library and the build fails. Before moving this code to Meson,
> + # we went through a dozen different commits affecting the usage of -no-pie,
> + # ultimately settling for a completely broken one that added -no-pie to the
> + # compiler flags together with -fno-pie... except that -no-pie is a linker
> + # flag that has no effect on the compiler command line. So, don't add
> + # -no-pie anywhere and cross fingers.
> endif
>
> if not get_option('stack_protector').disabled()
This removes this annoying warning with Clang on Aarch64:
clang: warning: argument unused during compilation: '-no-pie'
[-Wunused-command-line-argument]
Not tested on mingw64, but at least on Darwin:
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
© 2016 - 2024 Red Hat, Inc.