From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH v2 10/23] efi: build xen.gz with EFI code Date: Mon, 24 Aug 2015 05:35:21 -0600 Message-ID: <55DB1D99020000780009CAAC@prv-mh.provo.novell.com> References: <1437402558-7313-1-git-send-email-daniel.kiper@oracle.com> <1437402558-7313-11-git-send-email-daniel.kiper@oracle.com> <55D610DB020000780009C3F6@prv-mh.provo.novell.com> <20150822135919.GY7143@olila.local.net-space.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZTq2E-0005nI-Ik for xen-devel@lists.xenproject.org; Mon, 24 Aug 2015 11:35:30 +0000 In-Reply-To: <20150822135919.GY7143@olila.local.net-space.pl> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Daniel Kiper Cc: Juergen Gross , grub-devel@gnu.org, wei.liu2@citrix.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, roy.franz@linaro.org, ning.sun@intel.com, david.vrabel@citrix.com, phcoder@gmail.com, xen-devel@lists.xenproject.org, qiaowei.ren@intel.com, keir@xen.org, richard.l.maliszewski@intel.com, gang.wei@intel.com, fu.wei@linaro.org List-Id: xen-devel@lists.xenproject.org >>> On 22.08.15 at 15:59, wrote: > On Thu, Aug 20, 2015 at 09:39:39AM -0600, Jan Beulich wrote: >> >>> On 20.07.15 at 16:29, wrote: >> > Build xen.gz with EFI code. We need this to support multiboot2 >> > protocol on EFI platforms. >> > >> > If we wish to load not ELF file using multiboot (v1) or multiboot2 then >> >> DYM "a non-ELF file"? >> >> > it must contain "linear" (or "flat") representation of code and data. >> >> Why? Please don't just put out statements, but also reasons (i.e. >> at least which component is unable to deal with the current [valid >> afaict] PE image we have). > > This is a requirement of multiboot (v1) or multiboot2 protocol. They both > know nothing about PE image format. And hence how specifically we arrange data inside the image should be benign to them, as they won't be able to load the file _anyway_. >> > Currently, PE file contains many sections which are not "linear" (one >> > after another without any holes) or even do not have representation >> > in a file (e.g. BSS). In theory there is a chance that we could build >> > proper PE file using current build system. However, it means that >> >> What is "improper" about the currently built PE file? And if there is >> anything improper, did you inform the binutils maintainers of the >> problem? > > From PE loader point of view everything is OK. However, current Xen PE > image (at least build on my machines) is not usable by multiboot (v1) > or multiboot2 protocol compatible loader because it is not linear (one > section does not live immediately after another without any voids). Again - either I'm missing something (and then your explanation is not good enough) or this is (as said above) a pointless adjustment. >> > --- a/xen/arch/x86/efi/Makefile >> > +++ b/xen/arch/x86/efi/Makefile >> > @@ -1,14 +1,16 @@ >> > CFLAGS += -fshort-wchar >> > >> > -obj-y += stub.o >> > - >> > -create = test -e $(1) || touch -t 199901010000 $(1) >> > - >> > efi := $(filter y,$(x86_64)$(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 >disabled && echo y)) >> > -efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o); $(call create,runtime.o))) >> > +efi := $(if $(efi),$(shell rm disabled)y) >> > >> > -extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o >> > +extra-y += relocs-dummy.o >> >> Why is this no longer extra-$(efi)? > > Because we need proper EFI code in xen.gz to support boot > via multiboot2 on EFI platforms. What would we need that for when not building an EFI-capable binary anyway? >> > -stub.o: $(extra-y) >> >> With this dependency removed (instead of perhaps replaced or >> extended) - what will trigger relocs-dummy.o to be (re)built? > > It is triggered by prelink.o build rule in xen/arch/x86/Makefile. No. Or better - if it is, then this is wrong. With the way our build logic works, unless there are exceptional circumstances things in a certain directory should be built _only_ when recursion reaches that particular directory (i.e. not from any of its parents). Jan