[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] x86/EFI: suppress GNU ld 2.36'es creation of base relocs

  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Wed, 24 Feb 2021 17:17:34 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ACRe1/lP/czR45NXkhQIJMh21DLYFMN5IrpyGguX+ck=; b=N2EsGR1ivCwFjr0bVh26dLy33LdefT5rhjKH3vQfcepyU/CBYus047gFTgGt0uDDFWrx6UVpmutexln8c1yWixN4iW7IzrLVH7QPg9yABlZpfWBCrPOB5ZZ1r4fi8L4NUDXPw8Qn4o1Y9UaxmmD89geI237tD1Ysak6f1wDHXBBJEQuNzzzzFl8DcgvdC/cTJZIIEsKjF4LBTM6BTidCfpLKMzRnp8m9qxfs4Op33fYMjoCwJ+4NzLqfpYouHTDT7MK1EqkrvSA4gSoOsx44SRMvMffto4ip/bCHxiKKlKF0U3OzDnvF9XuZrUI53pblumpQfaClgx7G0uFKOzlK9A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y+/m3fhtZwah0ewvkzgDRzNcOeo8R/pa0CFwReu6fCBoYv/Vo7qLC9EqoiuLMq2PDdtKSEGRfgWnTYEKDfi7+cg0dk4eoeveE1OFqZBpnIFuuEdeCgXbnbfOzW0mYTtKHwlIptdJQUpOlUBMqVx/73QHNsN+nf56tFkSoBdl1MOyVypv20ePIZ2ccofvdfa3b+uhJ1eYVwdpRDvxcZBSKvCDnK8TisqKwitNnDsFb+gtMRdGrCYNYAsLKhfR+TPhbdcNpXAkkZdBxOXZvrrv76wq5METg3yiPQ6HtStxMh3TDYujOb2xBTRi0P6UHRB759DwkXRGYbubUPqQlhUvWQ==
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 24 Feb 2021 17:17:54 +0000
  • Ironport-sdr: 3DrsMFT3EncQfCKnrP4NXFbiKnzgfoJNu3K4zqLl5DB4KIEwgULSG6VKW6QDpTVwne/yuJvvDS P/3+QAo9iQcnfpycNnM3RPWiASxeWZqHNsi7XAYzOGzoqZ4+JgyDKj6xbstt0CsTdeh9IgaX03 xb+gTW7FZCi3+goeNS/9pz2X6okn/6EILB1SrK9Jr74BufzOPIDOqqRyy0CpQQr6qyVDe/ZGqj nTENxzWu4Eex8T9XF63DAJnUqlWdD9prlCKAD5rlzzgMSg5vzGrmJpmk+HWP3xLBudQOUEiVPl W1g=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 23/02/2021 07:53, Jan Beulich wrote:
> On 22.02.2021 17:36, Andrew Cooper wrote:
>> On 19/02/2021 08:09, Jan Beulich wrote:
>>> --- a/xen/arch/x86/Makefile
>>> +++ b/xen/arch/x86/Makefile
>>> @@ -123,8 +123,13 @@ ifneq ($(efi-y),)
>>>  # Check if the compiler supports the MS ABI.
>>>  export XEN_BUILD_EFI := $(shell $(CC) $(XEN_CFLAGS) -c efi/check.c -o 
>>> efi/check.o 2>/dev/null && echo y)
>>>  # Check if the linker supports PE.
>>> -XEN_BUILD_PE := $(if $(XEN_BUILD_EFI),$(shell $(LD) -mi386pep 
>>> --subsystem=10 -S -o efi/check.efi efi/check.o 2>/dev/null && echo y))
>>> +EFI_LDFLAGS = $(patsubst -m%,-mi386pep,$(XEN_LDFLAGS)) --subsystem=10 
>>> --strip-debug
>>> +XEN_BUILD_PE := $(if $(XEN_BUILD_EFI),$(shell $(LD) $(EFI_LDFLAGS) -o 
>>> efi/check.efi efi/check.o 2>/dev/null && echo y))
>>> +# Check if the linker produces fixups in PE by default (we need to disable 
>>> it doing so for now).
>>> +XEN_NO_PE_FIXUPS := $(if $(XEN_BUILD_EFI), \
>>> +                         $(shell $(LD) $(EFI_LDFLAGS) 
>>> --disable-reloc-section -o efi/check.efi efi/check.o 2>/dev/null && \
>>> +                                 echo --disable-reloc-section))
>> Why does --strip-debug move?
> -S and --strip-debug are the same. I'm simply accumulating in
> EFI_LDFLAGS all that's needed for the use in the probing construct.

Oh ok.

It occurs to me that EFI_LDFLAGS now only gets started in an ifneq
block, but appended to later on while unprotected.  That said, I'm
fairly sure it is only consumed inside a different ifeq section, so I
think there is a reasonable quantity of tidying which ought to be done here.

> Also I meanwhile have a patch to retain debug info, for which this
> movement turns out to be a prereq. (I've yet to test that the
> produced binary actually works, and what's more I first need to get
> a couple of changes accepted into binutils for the linker to actually
> cope.)
>> What's wrong with $(call ld-option ...) ?  Actually, lots of this block
>> of code looks to be opencoding of standard constructs.
> It looks like ld-option could indeed be used here (there are marginal
> differences which are likely acceptable), despite its brief comment
> talking of just "flag" (singular, plus not really covering e.g. input
> files).
> But:
> - It working differently than cc-option makes it inconsistent to
>   use (the setting of XEN_BUILD_EFI can't very well be switched to
>   use cc-option); because of this I'm not surprised that we have
>   only exactly one use right now in the tree.
> - While XEN_BUILD_PE wants to be set to "y", for XEN_NO_PE_FIXUPS
>   another transformation would then be necessary to translate "y"
>   into "--disable-reloc-section".
> - Do you really suggest to re-do this at this point in the release
>   cycle?

I'm looking to prevent this almost-incompressible mess from getting worse.

But I suppose you want this to backport, so I suppose it ought to be
minimally invasive.

Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

This logic all actually needs moving into Kconfig so we can also go
about fixing the other bugs we have such as having Multiboot headers in
xen.efi pointing at unusable entrypoints.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.