Two linkers - EFI one (mingw64) and normal GNU one [Fedora]

Two linkers - EFI one (mingw64) and normal GNU one [Fedora]

[Konrad Rzeszutek Wilk]

Hey,

Fedora for the longest time seems to have two linkers - one normal for GNU
applications and then another - mingw64 - for building EFI applications.

Which means that to compile ELF binaries on Fedora requires this patch
(taken from Fedora build):

>From 078f2d6155e940a91c1f668b86dcb9534d76b8b7 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 6 Jan 2016 16:39:23 -0500
Subject: [PATCH] EFI build using mingw

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Conflicts:
	xen/arch/x86/Makefile
---
 xen/Makefile              | 2 ++
 xen/arch/x86/Makefile     | 6 +++---
 xen/arch/x86/efi/Makefile | 2 +-
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/xen/Makefile b/xen/Makefile
index f702525..09c708c 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -20,6 +20,8 @@ export XEN_ROOT := $(BASEDIR)/..
 MAKEFLAGS += -rR
 
 EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi
+EFI_VENDOR=fedora
+LD_EFI ?= $(LD)
 
 ARCH=$(XEN_TARGET_ARCH)
 SRCARCH=$(shell echo $(ARCH) | sed -e 's/x86.*/x86/' -e s'/arm\(32\|64\)/arm/g')
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 5f7c57e..e010fa0 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -160,20 +160,20 @@ endif
 
 $(TARGET).efi: prelink-efi.o efi.lds efi/relocs-dummy.o $(BASEDIR)/common/symbols-dummy.o efi/mkreloc
 	$(foreach base, $(VIRT_BASE) $(ALT_BASE), \
-	          $(guard) $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< efi/relocs-dummy.o \
+	          $(guard) $(LD_EFI) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< efi/relocs-dummy.o \
 	                $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).$(base).0 &&) :
 	$(guard) efi/mkreloc $(foreach base,$(VIRT_BASE) $(ALT_BASE),$(@D)/.$(@F).$(base).0) >$(@D)/.$(@F).0r.S
 	$(guard) $(NM) -pa --format=sysv $(@D)/.$(@F).$(VIRT_BASE).0 \
 		| $(guard) $(BASEDIR)/tools/symbols --sysv --sort >$(@D)/.$(@F).0s.S
 	$(guard) $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0r.o $(@D)/.$(@F).0s.o
 	$(foreach base, $(VIRT_BASE) $(ALT_BASE), \
-	          $(guard) $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< \
+	          $(guard) $(LD_EFI) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< \
 	                $(@D)/.$(@F).0r.o $(@D)/.$(@F).0s.o -o $(@D)/.$(@F).$(base).1 &&) :
 	$(guard) efi/mkreloc $(foreach base,$(VIRT_BASE) $(ALT_BASE),$(@D)/.$(@F).$(base).1) >$(@D)/.$(@F).1r.S
 	$(guard) $(NM) -pa --format=sysv $(@D)/.$(@F).$(VIRT_BASE).1 \
 		| $(guard) $(BASEDIR)/tools/symbols --sysv --sort >$(@D)/.$(@F).1s.S
 	$(guard) $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o
-	$(guard) $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T efi.lds -N $< \
+	$(guard) $(LD_EFI) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T efi.lds -N $< \
 	                $(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o $(build_id_file) -o $@
 	if $(guard) false; then rm -f $@; echo 'EFI support disabled'; fi
 	rm -f $(@D)/.$(@F).[0-9]*
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index 5099430..a6dae4c 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -6,7 +6,7 @@ create = test -e $(1) || touch -t 199901010000 $(1)
 
 efi := y$(shell rm -f disabled)
 efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c check.c 2>disabled && echo y))
-efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o 2>disabled && echo y))
+efi := $(if $(efi),$(shell $(LD_EFI) -mi386pep --subsystem=10 -o check.efi check.o 2>disabled && echo y))
 efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o); $(call create,runtime.o)))
 
 extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o
-- 
2.1.0


Which is not very nice.

I was thinking that we could augment configure.ac to detect for this and if so, well here I am
not sure. The final step is that this:

LD_EFI=/usr/x86_64-w64-mingw32/bin/ld

exists. Usually the configure.ac ends up jamming those in tools/config.h as this:

#define QEMU_XEN_PATH "/usr/lib/xen/bin/qemu-system-i386"


But that is 'tools', and not 'xen'.

Would it be OK if the configure.ac jammed an config.h in 'xen' directory? But then somehow
the Config.mk has to read this and figure this out? Which is kind of hackish.


Or should I just attempt at making the Config.mk have these exact same checks that can be evaluated?


Preferences?

Re: Two linkers - EFI one (mingw64) and normal GNU one [Fedora]

[Ian Jackson]

Konrad Rzeszutek Wilk writes ("Two linkers - EFI one (mingw64) and normal GNU one [Fedora]"):
> Would it be OK if the configure.ac jammed an config.h in 'xen'
> directory? But then somehow the Config.mk has to read this and
> figure this out? Which is kind of hackish.

Until now, hypervisor developers have maintained that it should be
possible to build the hypervisor without running configure.

Your proposal is to have configure detect this problematic situation
and automatically make it work.  But that means that at least on
Fedora it will be necessary to run configure first.

So this proposal introduces new build system plumbing anomaly: there
would have to be an output from configure that is consumed by the xen
build - a thing which has been hitherto forbidden.

Personally I would be happy to relax the no-configure-for-hypervisor
rule entirely, or in this specific case.

But hypervisor developers may prefer something else.


If we do go down the route of having autoconf figure this out, it
should not be plumbed via config.h.  autoconf can already generate
makefile outputs.

Probably the answer would be a xen/config.autoconf.mk.in (or some such
filename) which is turned into xen/config.autoconf.mk by configure and
"-include"d from the Xen Makefile.

Ian.

Re: Two linkers - EFI one (mingw64) and normal GNU one [Fedora]

[Doug Goldstein]

[-- Attachment #1.1: Type: text/plain, Size: 1753 bytes --]

On 2/12/16 11:19 AM, Konrad Rzeszutek Wilk wrote:
> Hey,
> 
> Fedora for the longest time seems to have two linkers - one normal for GNU
> applications and then another - mingw64 - for building EFI applications.
> 
> Which means that to compile ELF binaries on Fedora requires this patch
> (taken from Fedora build):
> 
> From 078f2d6155e940a91c1f668b86dcb9534d76b8b7 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Wed, 6 Jan 2016 16:39:23 -0500
> Subject: [PATCH] EFI build using mingw
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Conflicts:
> 	xen/arch/x86/Makefile
> ---
>  xen/Makefile              | 2 ++
>  xen/arch/x86/Makefile     | 6 +++---
>  xen/arch/x86/efi/Makefile | 2 +-
>  3 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/Makefile b/xen/Makefile
> index f702525..09c708c 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -20,6 +20,8 @@ export XEN_ROOT := $(BASEDIR)/..
>  MAKEFLAGS += -rR
>  
>  EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi
> +LD_EFI ?= $(LD)

So I think doing this is reasonable to allow Fedora to override it. You
can even do a check that LD_EFI supports i386pep as a target and skip
doing the EFI build/install if it does not. Similar to the case when
EFI_VENDOR is not set.

I don't see what adding a configure.ac would buy you since you would
have to hardcode a number of different paths to check for a linker that
works because the path that Fedora uses is different from every other
distro I currently have access to.

The real question is why can't we change the EFI stub generation to be
closer to how Linux does it which doesn't have this same constraint.

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Two linkers - EFI one (mingw64) and normal GNU one [Fedora]

[Konrad Rzeszutek Wilk]

On February 12, 2016 5:17:42 PM EST, Doug Goldstein <cardoe@cardoe.com> wrote:
>On 2/12/16 11:19 AM, Konrad Rzeszutek Wilk wrote:
>> Hey,
>> 
>> Fedora for the longest time seems to have two linkers - one normal
>for GNU
>> applications and then another - mingw64 - for building EFI
>applications.
>> 
>> Which means that to compile ELF binaries on Fedora requires this
>patch
>> (taken from Fedora build):
>> 
>> From 078f2d6155e940a91c1f668b86dcb9534d76b8b7 Mon Sep 17 00:00:00
>2001
>> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Date: Wed, 6 Jan 2016 16:39:23 -0500
>> Subject: [PATCH] EFI build using mingw
>> 
>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> 
>> Conflicts:
>> 	xen/arch/x86/Makefile
>> ---
>>  xen/Makefile              | 2 ++
>>  xen/arch/x86/Makefile     | 6 +++---
>>  xen/arch/x86/efi/Makefile | 2 +-
>>  3 files changed, 6 insertions(+), 4 deletions(-)
>> 
>> diff --git a/xen/Makefile b/xen/Makefile
>> index f702525..09c708c 100644
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -20,6 +20,8 @@ export XEN_ROOT := $(BASEDIR)/..
>>  MAKEFLAGS += -rR
>>  
>>  EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi
>> +LD_EFI ?= $(LD)
>
>So I think doing this is reasonable to allow Fedora to override it. You
>can even do a check that LD_EFI supports i386pep as a target and skip
>doing the EFI build/install if it does not. Similar to the case when
>EFI_VENDOR is not set.
>
>I don't see what adding a configure.ac would buy you since you would
>have to hardcode a number of different paths to check for a linker that
>works because the path that Fedora uses is different from every other
>distro I currently have access to.

OK, which is why I was thinking of configure.ac trying different paths.

>
>The real question is why can't we change the EFI stub generation to be
>closer to how Linux does it which doesn't have this same constraint.

That is what Daniel suggested going forward.

 But that is a bit of further material.

Re: Two linkers - EFI one (mingw64) and normal GNU one [Fedora]

[Jan Beulich]

>>> On 12.02.16 at 18:19, <konrad.wilk@oracle.com> wrote:
> Fedora for the longest time seems to have two linkers - one normal for GNU
> applications and then another - mingw64 - for building EFI applications.
> 
> Which means that to compile ELF binaries on Fedora requires this patch
> (taken from Fedora build):

This seems completely backwards: Just like we (SUSE) did, they
should really configure their binutils package with
--enable-targets=<arch>-pep. I absolutely cannot see why a
MingW64 linker should be used to generate EFI binaries. Yes,
both use the same binary container format, but beyond that
there's nothing common here: EFI binaries are of no use in a
MingW64 environment (afaict at least), but are nowadays an
integral part of an OS installation (i.e. a Linux distro in this case).

If it can be proven that Fedora folks are absolutely unwilling to
do so, I could see something like what you propose as a
workaround (albeit it's more like a hack), so a few comments on
the patch itself:

> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -20,6 +20,8 @@ export XEN_ROOT := $(BASEDIR)/..
>  MAKEFLAGS += -rR
>  
>  EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi
> +EFI_VENDOR=fedora

This is a no-go. The variable specifically should only be set from
outside our build environment.

> +LD_EFI ?= $(LD)

Why couldn't you just probe the binary location(s) you know about
here? But in any case this would perhaps need better integration
with the checking done in xen/arch/x86/efi/Makefile.

Jan

Re: Two linkers - EFI one (mingw64) and normal GNU one [Fedora]

[Konrad Rzeszutek Wilk]

On Mon, Feb 15, 2016 at 02:32:45AM -0700, Jan Beulich wrote:
> >>> On 12.02.16 at 18:19, <konrad.wilk@oracle.com> wrote:
> > Fedora for the longest time seems to have two linkers - one normal for GNU
> > applications and then another - mingw64 - for building EFI applications.
> > 
> > Which means that to compile ELF binaries on Fedora requires this patch
> > (taken from Fedora build):
> 
> This seems completely backwards: Just like we (SUSE) did, they
> should really configure their binutils package with
> --enable-targets=<arch>-pep. I absolutely cannot see why a
> MingW64 linker should be used to generate EFI binaries. Yes,
> both use the same binary container format, but beyond that
> there's nothing common here: EFI binaries are of no use in a
> MingW64 environment (afaict at least), but are nowadays an
> integral part of an OS installation (i.e. a Linux distro in this case).

It has been like this for the last couple of releases. MA Young
has been CC-ed on this thread so hopefully he has some idea of why it
was choosen this way.
> 
> If it can be proven that Fedora folks are absolutely unwilling to
> do so, I could see something like what you propose as a
> workaround (albeit it's more like a hack), so a few comments on
> the patch itself:
> 
> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -20,6 +20,8 @@ export XEN_ROOT := $(BASEDIR)/..
> >  MAKEFLAGS += -rR
> >  
> >  EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi
> > +EFI_VENDOR=fedora
> 
> This is a no-go. The variable specifically should only be set from
> outside our build environment.

Right.
> 
> > +LD_EFI ?= $(LD)
> 
> Why couldn't you just probe the binary location(s) you know about
> here? But in any case this would perhaps need better integration
> with the checking done in xen/arch/x86/efi/Makefile.

<nods>
I can certainly do that.

Doug, does Gentoo have it in some other locations?
> 
> Jan
> 

Re: Two linkers - EFI one (mingw64) and normal GNU one [Fedora]

[Doug Goldstein]

[-- Attachment #1.1: Type: text/plain, Size: 1424 bytes --]

On 2/15/16 8:26 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 15, 2016 at 02:32:45AM -0700, Jan Beulich wrote:
>>>>> On 12.02.16 at 18:19, <konrad.wilk@oracle.com> wrote:
>>> Fedora for the longest time seems to have two linkers - one normal for GNU
>>> applications and then another - mingw64 - for building EFI applications.
>>>
>>> Which means that to compile ELF binaries on Fedora requires this patch
>>> (taken from Fedora build):
>>
>> This seems completely backwards: Just like we (SUSE) did, they
>> should really configure their binutils package with
>> --enable-targets=<arch>-pep. I absolutely cannot see why a
>> MingW64 linker should be used to generate EFI binaries. Yes,
>> both use the same binary container format, but beyond that
>> there's nothing common here: EFI binaries are of no use in a
>> MingW64 environment (afaict at least), but are nowadays an
>> integral part of an OS installation (i.e. a Linux distro in this case).
>>
>>> +LD_EFI ?= $(LD)
>>
>> Why couldn't you just probe the binary location(s) you know about
>> here? But in any case this would perhaps need better integration
>> with the checking done in xen/arch/x86/efi/Makefile.
> 
> <nods>
> I can certainly do that.
> 
> Doug, does Gentoo have it in some other locations?
>>
>> Jan
>>

Gentoo does --enable-targets=<arch>-pep so our default ld can generate
EFI binaries.

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel