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

Re: [PATCH] x86/build: use --orphan-handling linker option if available


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Thu, 3 Mar 2022 16:09:53 +0100
  • 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UqaQBEpyIqc9Ja+A48GISfACovbD0WUo0m4jHCbVC7k=; b=AALoqIt6zHwL645o+jnWKG+UOfyjgi8EvtDBQkFgb7DrxAKyKcPscLSGDrscX4RPEfsJYx/jA/C3B+c68vWNDvW2xuKFIE+xsa9sok8rbjqNBW6C9EL2+v9R8ScAAhRwrmyHkr1QIr1tSzVjaDJ6HfyJza1B+6LyuyFV4YraEvFfsoT68xa2lyKgc0+Ru0UpPkDnCCjCRYIdvnBJBDRVgxIiCiTeP8PHvOXDNMeryQ/GQ8/5HafftgAvMqFN+ekDbCBmaLhJ3PdudU2Irlq0wTOgGsZJd8nmbiqMUV/JSWyGpywDFPOuDHk71q3OHdUnb1WUQ8gEhBWEHp4Ulk8qYQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dlh6HZGMpH3FV7Oy2K1lcLMKEi+YyqjcOwC0+9N8XqzgKQLJTwwvpmV1DcaQLoAlxkOetmbuQq9etBpTnBN4mekuh5oQUZ9vYx8UIRGQYnvlFdtM/al1RQknJZbvh2xA/K84VjmYhAMbCnYdbf9801hsQuhXSFEaGhPeecq9WOZPKMKvvs0FqRqERxa/PlkQl9FtDBMAuOHxLTopIeAJ8+zp0fHUi2gI0gVUK8dkQ19nunL6i2rlBWUXrpcK1X3n1vJxvrH/6gymugtAFy8P1/pSM98FLFSZRxzgN6EGtABMjLYtWxaNflZkTM1z9uDUSnB8X/JWRGukzvVMRme9gw==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Thu, 03 Mar 2022 15:10:11 +0000
  • Ironport-data: A9a23:lIG+Fq+NZUC/5/pIshsMDrUDnX6TJUtcMsCJ2f8bNWPcYEJGY0x3n TAcWGHSPqqJZjegetwgOdzg804Gu5LXmoRnTgdory08E34SpcT7XtnIdU2Y0wF+jyHgoOCLy +1EN7Es+ehtFie0Si+Fa+Sn9T8mvU2xbuKU5NTsY0idfic5DnZ54f5fs7Rh2NQw2oDiW1nlV e7a+KUzBnf0g1aYDUpMg06zgEsHUCPa4W5wUvQWPJinjXeG/5UnJMt3yZKZdhMUdrJ8DO+iL 9sv+Znilo/vE7XBPfv++lrzWhVirrc/pmFigFIOM0SpqkAqSiDfTs/XnRfTAKtao2zhojx/9 DlCnbjgGRckJ4rjorkmCQRVKQRhM/J5/qCSdBBTseTLp6HHW37lwvEoB0AqJ4wIvO1wBAmi9 9RBdmpLNErawbvrnvTrEYGAhex6RCXvFJkYtXx6iynQEN4tQIzZQrWM7thdtNs1rp4TRqeDP pdHAdZpRCjwPTtSKnk3MsodsNf3qFTCbh1opXvA8MLb5ECMlVcsgdABKuH9ZdiiVchT2EGCq Qru72n/Rx0XKtGb4T6E6W63wP/CmzvhX4AfH6H+8eRl6HWRzGEODBwdVXOgvOK0zEW5Xrpix 1c8o3R06/JorQryE4e7D0bQTGO4UgA0f4oAA+Ajzy63l5GO/gujI3cKEQFHd4lz3CMpfgAC2 liMltLvIDVgtryJVH6QnoupQSOO1Ts9djFbO3JdJecRy5y6+dxo0EqTJjp2OPPt1rXI9SfML ydmRcTUr5EaloY12qqy5jgraBr898GSHmbZCug6N19JDz+Vhqb4P+RECnCBtJ6sybp1qHHb5 hDofODEsYgz4WmlznDlfQn0NOjBCwy5GDPdm0VzOJIq6i6g/XWuFagJvm0gfhs3bpdfJmKwC KM2he+3zMUJVJdNRfUqC79d9uxwlfSwfTgbfqq8giVyjmhZK1bcoXAGib+41GHxikk8+ZzTy r/AGftA+U0yUPw9pBLvHr91+eZymkgWnDqDLbimn0XP+efPPxa9FOZaWGZim8hktctoVi2Oq I0BXyZLoj0CONDDjt7/qtZCfQhXdiFgXfgbaaV/L4a+H+avI0l4Y9f5yrI9YY112aNTk+bD5 HamXUFEjlH4gBX6xc+iMxiPtJuHsU5DkE8G
  • Ironport-hdrordr: A9a23:FdfipKCpYTe2d5nlHehOsceALOsnbusQ8zAXPh9KJiC9I/b1qy nxppkmPH/P6Qr4WBkb6Le90Y27MAnhHPlOkPQs1NaZLXLbUQ6TQr2KgrGSoQEIdxeOk9K1kJ 0QD5SWa+eAfGSS7/yKmTVQeuxIqLLskNHKuQ6d9QYUcegDUdAf0+4TMHf8LqQZfngjOXJvf6 Dsmfav6gDQMUg/X4CePD0oTuLDr9rEmNbPZgMHPQcu7E2rgSmz4LD3PhCE1lNGOgk/i4sKwC zgqUjU96+ju/a0xlv10HLS1Y1fnJ/ExsFYDMKBp8AJInHHixquZq5mR7qe1QpF692H2RIPqp 3hsh0gN8N85zf4eXy0mwLk303a3DMn+xbZuCilqEqmhfa8aCMxCsJHi44cWADe8VAcsNZ117 8O936FtrJMZCmw0xjV1pztbVVHh0C0qX0tnao4lHpES7YTb7dXsMg24F5VKpEdByj3gbpXXN WGNPuspcq+TGnqL0ww5gJUsZ+RtzUIb1q7q3E5y4KoO2M8pgE686MarPZv6kvouqhNDqWs3N 60QZiApIs+PvP+UpgNdtvpYfHHfFAlEii8eV57HzzcZdQ60jT22trK3Ik=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Mar 03, 2022 at 01:17:03PM +0100, Jan Beulich wrote:
> On 03.03.2022 12:19, Roger Pau Monné wrote:
> > On Wed, Mar 02, 2022 at 03:19:35PM +0100, Jan Beulich wrote:
> >> As was e.g. making necessary 4b7fd8153ddf ("x86: fold sections in final
> >> binaries"), arbitrary sections appearing without our linker script
> >> placing them explicitly can be a problem. Have the linker make us aware
> >> of such sections, so we would know that the script needs adjusting.
> >>
> >> To deal with the resulting warnings:
> >> - Retain .note.* explicitly for ELF, and discard all of them (except the
> >>   earlier consumed .note.gnu.build-id) for PE/COFF.
> >> - Have explicit statements for .got, .plt, and alike and add assertions
> >>   that they're empty. No output sections will be created for these as
> >>   long as they remain empty (or else the assertions would cause early
> >>   failure anyway).
> >> - Collect all .rela.* into a single section, with again an assertion
> >>   added for the resulting section to be empty.
> >> - Extend the enumerating of .debug_* to ELF. Note that for Clang adding
> >>   of .debug_macinfo is necessary. Amend this by its Dwarf5 counterpart,
> >>   .debug_macro, then as well (albeit more may need adding for full
> >>   coverage).
> >>
> >> Suggested-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> >> ---
> >> I would have wanted to make this generic (by putting it in
> >> xen/Makefile), but the option cannot be added to LDFLAGS, or else
> >> there'll be a flood of warnings with $(LD) -r. (Besides, adding to
> >> LDFLAGS would mean use of the option on every linker pass rather than
> >> just the last one.)
> >>
> >> Retaining of .note in xen-syms is under question. Plus if we want to
> >> retain all notes, the question is whether they wouldn't better go into
> >> .init.rodata. But .note.gnu.build-id shouldn't move there, and when
> >> notes are discontiguous all intermediate space will also be assigned to
> >> the NOTE segment, thus making the contents useless for tools going just
> >> by program headers.
> >>
> >> Newer Clang may require yet more .debug_* to be added. I've only played
> >> with versions 5 and 7 so far.
> >>
> >> Unless we would finally drop all mentioning of Stabs sections, we may
> >> want to extend to there what is done for Dwarf here (allowing the EFI
> >> conditional around the section to also go away).
> >>
> >> See also https://sourceware.org/pipermail/binutils/2022-March/119922.html.
> > 
> > LLD 13.0.0 also warns about:
> > 
> > ld: warning: <internal>:(.symtab) is being placed in '.symtab'
> > ld: warning: <internal>:(.shstrtab) is being placed in '.shstrtab'
> > ld: warning: <internal>:(.strtab) is being placed in '.strtab'
> > 
> > So seeing your mail where you mention GNU ld not needing those, I
> > think we would need to add them anyway for LLVM ld.
> 
> Hmm, that's ugly. How do I recognize LLVM ld? I can't simply use a
> pre-processor conditional keying off of __clang__, as that used as the
> compiler doesn't mean their ld is also in use (typically the case on
> Linux).

Hard to tell, `ld -v` for LLD will typically contain '^LLD' I think,
but I don't really like matching on human readable output like this.

> I also don't want to add these uniformly, for now knowing what
> side effects their mentioning might have with GNU ld.

Wouldn't it be fine to just place them at the end, just like it's
done by default by ld?

Are you worried about not getting the proper type if mentioned in the
linker script?

> >> --- a/xen/arch/x86/Makefile
> >> +++ b/xen/arch/x86/Makefile
> >> @@ -120,6 +120,8 @@ syms-warn-dup-y := --warn-dup
> >>  syms-warn-dup-$(CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS) :=
> >>  syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --error-dup
> >>  
> >> +orphan-handling-$(call ld-option,--orphan-handling=warn) += 
> >> --orphan-handling=warn
> > 
> > Might be better to place in xen/Kconfig with the CC checks?
> 
> Well. I've tried to stay away from complaining if people introduce
> new tool chain capability checks in Kconfig. But I'm not going to
> add any myself (unless things would become really inconsistent) up
> and until we have actually properly discussed the upsides and
> downsides of either model. Doing this via email (see the "Kconfig
> vs tool chain capabilities" thread started in August 2020) has
> proven to not lead anywhere. I'm really hoping that we can finally
> sort this in Bukarest.
> 
> > I'm also wondering whether we could add the flag here into XEN_LDFLAGS
> > and EFI_LDFLAGS, as those options are only used together with the
> > linker script in the targets on the Makefile.
> 
> Not for XEN_LDFLAGS at least, and undesirable for EFI_LDFLAGS. See
> the respective post-commit message remark.

But the calls to LD in order to generate $(TARGET)-syms do not use -r,
and are all using the linker script, so it should be fine to use
--orphan-handling=warn there?

Could we do something like:

$(TARGET)-syms: XEN_LDFLAGS += ...

And similar for $(TARGET).efi?

> >> --- a/xen/arch/x86/xen.lds.S
> >> +++ b/xen/arch/x86/xen.lds.S
> >> @@ -12,6 +12,12 @@
> >>  #undef __XEN_VIRT_START
> >>  #define __XEN_VIRT_START __image_base__
> >>  #define DECL_SECTION(x) x :
> >> +/*
> >> + * Use the NOLOAD directive, despite currently ignored by ld for PE 
> >> output, in
> > 
> > Would you mind adding GNU ld here to avoid confusion?
> 
> I've done so, but I'm not sure if implicitly you mean to say that
> LLVM ld does honor the directive when linking xen.efi? If that
> wasn't the case, it would rather seem misleading to have "GNU"
> there. Unless e.g. LLVM ld can't link xen.efi at all ...

So the one installed by default on FreeBSD doesn't have support for the
i386pep target emulation built in. AFAICT the EFI loader on FreeBDS is
built using a pre-made PE header and assembled together using objcopy.

Thanks, Roger.



 


Rackspace

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