qemu-user: fix build with LLVM lld 10

Commit Message

Roger Pau Monne March 26, 2020, 1:43 p.m. UTC

lld 10.0.0 introduced a new linker option --image-base equivalent to
the GNU -Ttext-segment one, hence use it when available.

This fixes the build of QEMU on systems using lld 10 or greater.

Signed-off-by: Dimitry Andric <[e-mail]>
Signed-off-by: Roger Pau Monné <[e-mail]>
---
Cc: Laurent Vivier <[e-mail]>
Cc: Richard Henderson <[e-mail]>
Cc: "Philippe Mathieu-Daudé" <[e-mail]>
Cc: Paolo Bonzini <[e-mail]>
Cc: "Daniel P. Berrangé" <[e-mail]>
---
 configure | 42 +++++++++++++++++++++++-------------------
 1 file changed, 23 insertions(+), 19 deletions(-)

Comments

Richard Henderson March 26, 2020, 4:56 p.m. UTC | #1

On 3/26/20 6:43 AM, Roger Pau Monne wrote:
> lld 10.0.0 introduced a new linker option --image-base equivalent to
> the GNU -Ttext-segment one, hence use it when available.
> 
> This fixes the build of QEMU on systems using lld 10 or greater.
> 
> Signed-off-by: Dimitry Andric <[e-mail]>
> Signed-off-by: Roger Pau Monné <[e-mail]>
> ---
> Cc: Laurent Vivier <[e-mail]>
> Cc: Richard Henderson <[e-mail]>
> Cc: "Philippe Mathieu-Daudé" <[e-mail]>
> Cc: Paolo Bonzini <[e-mail]>
> Cc: "Daniel P. Berrangé" <[e-mail]>
> ---

The Plan is still to drop this whole section of code.

However, it's still blocked on getting the x86_64 vsyscall patches upstream.


r~

Roger Pau Monne March 27, 2020, 10:16 a.m. UTC | #2

On Thu, Mar 26, 2020 at 09:56:38AM -0700, Richard Henderson wrote:
> On 3/26/20 6:43 AM, Roger Pau Monne wrote:
> > lld 10.0.0 introduced a new linker option --image-base equivalent to
> > the GNU -Ttext-segment one, hence use it when available.
> > 
> > This fixes the build of QEMU on systems using lld 10 or greater.
> > 
> > Signed-off-by: Dimitry Andric <[e-mail]>
> > Signed-off-by: Roger Pau Monné <[e-mail]>
> > ---
> > Cc: Laurent Vivier <[e-mail]>
> > Cc: Richard Henderson <[e-mail]>
> > Cc: "Philippe Mathieu-Daudé" <[e-mail]>
> > Cc: Paolo Bonzini <[e-mail]>
> > Cc: "Daniel P. Berrangé" <[e-mail]>
> > ---
> 
> The Plan is still to drop this whole section of code.
> 
> However, it's still blocked on getting the x86_64 vsyscall patches upstream.

While this doesn't materialize, could it be possible to get this patch
accepted?

This is currently blocking the build of QEMU on FreeBSD HEAD, which
has already switched to LLVM 10.0.0.

Thanks, Roger.

Laurent Vivier March 27, 2020, 10:51 a.m. UTC | #3

Le 26/03/2020 à 17:56, Richard Henderson a écrit :
> On 3/26/20 6:43 AM, Roger Pau Monne wrote:
>> lld 10.0.0 introduced a new linker option --image-base equivalent to
>> the GNU -Ttext-segment one, hence use it when available.
>>
>> This fixes the build of QEMU on systems using lld 10 or greater.
>>
>> Signed-off-by: Dimitry Andric <[e-mail]>
>> Signed-off-by: Roger Pau Monné <[e-mail]>
>> ---
>> Cc: Laurent Vivier <[e-mail]>
>> Cc: Richard Henderson <[e-mail]>
>> Cc: "Philippe Mathieu-Daudé" <[e-mail]>
>> Cc: Paolo Bonzini <[e-mail]>
>> Cc: "Daniel P. Berrangé" <[e-mail]>
>> ---
> 
> The Plan is still to drop this whole section of code.
> 
> However, it's still blocked on getting the x86_64 vsyscall patches upstream.

Richard,

will you propose another fix to fix build with LLVM lld 10?

Thanks,
Laurent

Alex Bennée March 27, 2020, 11:28 a.m. UTC | #4

Roger Pau Monné <[e-mail]> writes:

> On Thu, Mar 26, 2020 at 09:56:38AM -0700, Richard Henderson wrote:
>> On 3/26/20 6:43 AM, Roger Pau Monne wrote:
>> > lld 10.0.0 introduced a new linker option --image-base equivalent to
>> > the GNU -Ttext-segment one, hence use it when available.
>> > 
>> > This fixes the build of QEMU on systems using lld 10 or greater.
>> > 
>> > Signed-off-by: Dimitry Andric <[e-mail]>
>> > Signed-off-by: Roger Pau Monné <[e-mail]>
>> > ---
>> > Cc: Laurent Vivier <[e-mail]>
>> > Cc: Richard Henderson <[e-mail]>
>> > Cc: "Philippe Mathieu-Daudé" <[e-mail]>
>> > Cc: Paolo Bonzini <[e-mail]>
>> > Cc: "Daniel P. Berrangé" <[e-mail]>
>> > ---
>> 
>> The Plan is still to drop this whole section of code.
>> 
>> However, it's still blocked on getting the x86_64 vsyscall patches upstream.
>
> While this doesn't materialize, could it be possible to get this patch
> accepted?
>
> This is currently blocking the build of QEMU on FreeBSD HEAD, which
> has already switched to LLVM 10.0.0.

I think the vsyscall patch has just been merged, however way I don't
think targeting HEAD of a OS release during the rc phase is appropriate.

Roger Pau Monne March 27, 2020, 2:08 p.m. UTC | #5

On Fri, Mar 27, 2020 at 11:28:04AM +0000, Alex Bennée wrote:
> 
> Roger Pau Monné <[e-mail]> writes:
> 
> > On Thu, Mar 26, 2020 at 09:56:38AM -0700, Richard Henderson wrote:
> >> On 3/26/20 6:43 AM, Roger Pau Monne wrote:
> >> > lld 10.0.0 introduced a new linker option --image-base equivalent to
> >> > the GNU -Ttext-segment one, hence use it when available.
> >> > 
> >> > This fixes the build of QEMU on systems using lld 10 or greater.
> >> > 
> >> > Signed-off-by: Dimitry Andric <[e-mail]>
> >> > Signed-off-by: Roger Pau Monné <[e-mail]>
> >> > ---
> >> > Cc: Laurent Vivier <[e-mail]>
> >> > Cc: Richard Henderson <[e-mail]>
> >> > Cc: "Philippe Mathieu-Daudé" <[e-mail]>
> >> > Cc: Paolo Bonzini <[e-mail]>
> >> > Cc: "Daniel P. Berrangé" <[e-mail]>
> >> > ---
> >> 
> >> The Plan is still to drop this whole section of code.
> >> 
> >> However, it's still blocked on getting the x86_64 vsyscall patches upstream.
> >
> > While this doesn't materialize, could it be possible to get this patch
> > accepted?
> >
> > This is currently blocking the build of QEMU on FreeBSD HEAD, which
> > has already switched to LLVM 10.0.0.
> 
> I think the vsyscall patch has just been merged, however way I don't
> think targeting HEAD of a OS release during the rc phase is appropriate.

I'm not sure I understand what you mean. If QEMU doesn't build on
FreeBSD HEAD it won't build on the next release. Also the LLVM
toolchain used is not a development version AFAIK, but the actual
10.0.0 release, which QEMU should aim to support?

Can this be applied to stable branches then please if QEMU master
doesn't have that chunk in configure anymore?

FWIW, I've just looked at configure from git master branch and it
still has that exact same linker detection chunk that this patch is
trying to fix.

Thanks, Roger.

Alex Bennée March 27, 2020, 3:44 p.m. UTC | #6

Roger Pau Monné <[e-mail]> writes:

> On Fri, Mar 27, 2020 at 11:28:04AM +0000, Alex Bennée wrote:
>> 
>> Roger Pau Monné <[e-mail]> writes:
>> 
>> > On Thu, Mar 26, 2020 at 09:56:38AM -0700, Richard Henderson wrote:
>> >> On 3/26/20 6:43 AM, Roger Pau Monne wrote:
>> >> > lld 10.0.0 introduced a new linker option --image-base equivalent to
>> >> > the GNU -Ttext-segment one, hence use it when available.
>> >> > 
>> >> > This fixes the build of QEMU on systems using lld 10 or greater.
>> >> > 
>> >> > Signed-off-by: Dimitry Andric <[e-mail]>
>> >> > Signed-off-by: Roger Pau Monné <[e-mail]>
>> >> > ---
>> >> > Cc: Laurent Vivier <[e-mail]>
>> >> > Cc: Richard Henderson <[e-mail]>
>> >> > Cc: "Philippe Mathieu-Daudé" <[e-mail]>
>> >> > Cc: Paolo Bonzini <[e-mail]>
>> >> > Cc: "Daniel P. Berrangé" <[e-mail]>
>> >> > ---
>> >> 
>> >> The Plan is still to drop this whole section of code.
>> >> 
>> >> However, it's still blocked on getting the x86_64 vsyscall patches upstream.
>> >
>> > While this doesn't materialize, could it be possible to get this patch
>> > accepted?
>> >
>> > This is currently blocking the build of QEMU on FreeBSD HEAD, which
>> > has already switched to LLVM 10.0.0.
>> 
>> I think the vsyscall patch has just been merged, however way I don't
>> think targeting HEAD of a OS release during the rc phase is appropriate.
>
> I'm not sure I understand what you mean. If QEMU doesn't build on
> FreeBSD HEAD it won't build on the next release. Also the LLVM
> toolchain used is not a development version AFAIK, but the actual
> 10.0.0 release, which QEMU should aim to support?

QEMU's supported build platforms are based on what is currently shipping
as stable versions:

  https://www.qemu.org/docs/master/system/build-platforms.html

> Can this be applied to stable branches then please if QEMU master
> doesn't have that chunk in configure anymore?

Usually platforms released after a given QEMU release will just carry
their own patches in the local packaging. When is the current HEAD due
to be cut as the next release? The schedule for QEMU's release is
documented on out planning pages:

  https://wiki.qemu.org/Planning/5.0

> FWIW, I've just looked at configure from git master branch and it
> still has that exact same linker detection chunk that this patch is
> trying to fix.

Now the vsyscalls patch is in this can be cleaned up I think. Richard?

Daniel P. Berrangé March 27, 2020, 3:48 p.m. UTC | #7

On Fri, Mar 27, 2020 at 03:44:47PM +0000, Alex Bennée wrote:
> 
> Roger Pau Monné <[e-mail]> writes:
> 
> > On Fri, Mar 27, 2020 at 11:28:04AM +0000, Alex Bennée wrote:
> >> 
> >> Roger Pau Monné <[e-mail]> writes:
> >> 
> >> > On Thu, Mar 26, 2020 at 09:56:38AM -0700, Richard Henderson wrote:
> >> >> On 3/26/20 6:43 AM, Roger Pau Monne wrote:
> >> >> > lld 10.0.0 introduced a new linker option --image-base equivalent to
> >> >> > the GNU -Ttext-segment one, hence use it when available.
> >> >> > 
> >> >> > This fixes the build of QEMU on systems using lld 10 or greater.
> >> >> > 
> >> >> > Signed-off-by: Dimitry Andric <[e-mail]>
> >> >> > Signed-off-by: Roger Pau Monné <[e-mail]>
> >> >> > ---
> >> >> > Cc: Laurent Vivier <[e-mail]>
> >> >> > Cc: Richard Henderson <[e-mail]>
> >> >> > Cc: "Philippe Mathieu-Daudé" <[e-mail]>
> >> >> > Cc: Paolo Bonzini <[e-mail]>
> >> >> > Cc: "Daniel P. Berrangé" <[e-mail]>
> >> >> > ---
> >> >> 
> >> >> The Plan is still to drop this whole section of code.
> >> >> 
> >> >> However, it's still blocked on getting the x86_64 vsyscall patches upstream.
> >> >
> >> > While this doesn't materialize, could it be possible to get this patch
> >> > accepted?
> >> >
> >> > This is currently blocking the build of QEMU on FreeBSD HEAD, which
> >> > has already switched to LLVM 10.0.0.
> >> 
> >> I think the vsyscall patch has just been merged, however way I don't
> >> think targeting HEAD of a OS release during the rc phase is appropriate.
> >
> > I'm not sure I understand what you mean. If QEMU doesn't build on
> > FreeBSD HEAD it won't build on the next release. Also the LLVM
> > toolchain used is not a development version AFAIK, but the actual
> > 10.0.0 release, which QEMU should aim to support?
> 
> QEMU's supported build platforms are based on what is currently shipping
> as stable versions:
> 
>   https://www.qemu.org/docs/master/system/build-platforms.html

FWIW, when I wrote that my intention was *not* to exclude the bleeding
edge distro development branches.

Obviously we can break on those distros at any time as they're moving
targets, but IMHO we should treat bugs as we would for any other
released distros and aim to fix them promptly when bugs occurr.

Regards,
Daniel

Alex Bennée March 27, 2020, 3:57 p.m. UTC | #8

Daniel P. Berrangé <[e-mail]> writes:

> On Fri, Mar 27, 2020 at 03:44:47PM +0000, Alex Bennée wrote:
>> 
>> Roger Pau Monné <[e-mail]> writes:
>> 
>> > On Fri, Mar 27, 2020 at 11:28:04AM +0000, Alex Bennée wrote:
>> >> 
>> >> Roger Pau Monné <[e-mail]> writes:
>> >> 
>> >> > On Thu, Mar 26, 2020 at 09:56:38AM -0700, Richard Henderson wrote:
>> >> >> On 3/26/20 6:43 AM, Roger Pau Monne wrote:
>> >> >> > lld 10.0.0 introduced a new linker option --image-base equivalent to
>> >> >> > the GNU -Ttext-segment one, hence use it when available.
>> >> >> > 
>> >> >> > This fixes the build of QEMU on systems using lld 10 or greater.
>> >> >> > 
>> >> >> > Signed-off-by: Dimitry Andric <[e-mail]>
>> >> >> > Signed-off-by: Roger Pau Monné <[e-mail]>
>> >> >> > ---
>> >> >> > Cc: Laurent Vivier <[e-mail]>
>> >> >> > Cc: Richard Henderson <[e-mail]>
>> >> >> > Cc: "Philippe Mathieu-Daudé" <[e-mail]>
>> >> >> > Cc: Paolo Bonzini <[e-mail]>
>> >> >> > Cc: "Daniel P. Berrangé" <[e-mail]>
>> >> >> > ---
>> >> >> 
>> >> >> The Plan is still to drop this whole section of code.
>> >> >> 
>> >> >> However, it's still blocked on getting the x86_64 vsyscall patches upstream.
>> >> >
>> >> > While this doesn't materialize, could it be possible to get this patch
>> >> > accepted?
>> >> >
>> >> > This is currently blocking the build of QEMU on FreeBSD HEAD, which
>> >> > has already switched to LLVM 10.0.0.
>> >> 
>> >> I think the vsyscall patch has just been merged, however way I don't
>> >> think targeting HEAD of a OS release during the rc phase is appropriate.
>> >
>> > I'm not sure I understand what you mean. If QEMU doesn't build on
>> > FreeBSD HEAD it won't build on the next release. Also the LLVM
>> > toolchain used is not a development version AFAIK, but the actual
>> > 10.0.0 release, which QEMU should aim to support?
>> 
>> QEMU's supported build platforms are based on what is currently shipping
>> as stable versions:
>> 
>>   https://www.qemu.org/docs/master/system/build-platforms.html
>
> FWIW, when I wrote that my intention was *not* to exclude the bleeding
> edge distro development branches.
>
> Obviously we can break on those distros at any time as they're moving
> targets, but IMHO we should treat bugs as we would for any other
> released distros and aim to fix them promptly when bugs occurr.

Sure - I think there are now patches incoming from Richard to delete the
linker code which should meet the criteria for an RC fix, especially if
they solve the LLVM 10.0 problem as well.

Richard Henderson March 27, 2020, 11 p.m. UTC | #9

On 3/27/20 3:51 AM, Laurent Vivier wrote:
>> The Plan is still to drop this whole section of code.
>>
>> However, it's still blocked on getting the x86_64 vsyscall patches upstream.
> 
> Richard,
> 
> will you propose another fix to fix build with LLVM lld 10?

Sent.

r~

Patch

diff --git a/configure b/configure
index da09c35895..92d57d84fa 100755
--- a/configure
+++ b/configure
@@ -6514,27 +6514,31 @@  if ( [ "$linux_user" = yes ] || [ "$bsd_user" = yes ] ) && [ "$pie" = no ]; then
     cat > $TMPC <<EOF
     int main(void) { return 0; }
 EOF
-    textseg_ldflags="-Wl,-Ttext-segment=$textseg_addr"
+    # Test with image-base first, which appeared in lld 10.0.0
+    textseg_ldflags="-Wl,--image-base=$textseg_addr"
     if ! compile_prog "" "$textseg_ldflags"; then
-      # In case ld does not support -Ttext-segment, edit the default linker
-      # script via sed to set the .text start addr.  This is needed on FreeBSD
-      # at least.
-      if ! $ld --verbose >/dev/null 2>&1; then
-        error_exit \
-            "We need to link the QEMU user mode binaries at a" \
-            "specific text address. Unfortunately your linker" \
-            "doesn't support either the -Ttext-segment option or" \
-            "printing the default linker script with --verbose." \
-            "If you don't want the user mode binaries, pass the" \
-            "--disable-user option to configure."
-      fi
+      textseg_ldflags="-Wl,-Ttext-segment=$textseg_addr"
+      if ! compile_prog "" "$textseg_ldflags"; then
+        # In case ld does not support -Ttext-segment, edit the default linker
+        # script via sed to set the .text start addr.  This is needed on FreeBSD
+        # at least.
+        if ! $ld --verbose >/dev/null 2>&1; then
+          error_exit \
+              "We need to link the QEMU user mode binaries at a" \
+              "specific text address. Unfortunately your linker" \
+              "doesn't support either the --image-base or -Ttext-segment" \
+              "options or printing the default linker script with" \
+              "--verbose. If you don't want the user mode binaries," \
+              "pass the --disable-user option to configure."
+        fi
 
-      $ld --verbose | sed \
-        -e '1,/==================================================/d' \
-        -e '/==================================================/,$d' \
-        -e "s/[.] = [0-9a-fx]* [+] SIZEOF_HEADERS/. = $textseg_addr + SIZEOF_HEADERS/" \
-        -e "s/__executable_start = [0-9a-fx]*/__executable_start = $textseg_addr/" > config-host.ld
-      textseg_ldflags="-Wl,-T../config-host.ld"
+        $ld --verbose | sed \
+          -e '1,/==================================================/d' \
+          -e '/==================================================/,$d' \
+          -e "s/[.] = [0-9a-fx]* [+] SIZEOF_HEADERS/. = $textseg_addr + SIZEOF_HEADERS/" \
+          -e "s/__executable_start = [0-9a-fx]*/__executable_start = $textseg_addr/" > config-host.ld
+        textseg_ldflags="-Wl,-T../config-host.ld"
+      fi
     fi
   fi
 fi