Re: [Xen-devel] [PATCH v2 10/23] efi: build xen.gz with EFI code

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.08.15 at 15:59, <daniel.kiper@xxxxxxxxxx> wrote:
> On Thu, Aug 20, 2015 at 09:39:39AM -0600, Jan Beulich wrote:
>> >>> On 20.07.15 at 16:29, <daniel.kiper@xxxxxxxxxx> 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


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