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

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


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Tue, 8 Mar 2022 11:12:59 +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=Zfdpb/i6GfctBoPXNLrBBbStHRD2B0CfueJsk5WpLLQ=; b=I/Vxusjm06eIQNRdkp7PEMc74fAKIiZwWxbIQ8bJYe3DMwGsMZoe9HwMZZ0KSl5Q45xHehdhk2eHEoXM09TSLsHzf7IrlVBnzmU+i4aB3E9ACl8g5xLYZS5MASihLvxwkBe5Juxv07j5JPmDixTVB2nr9FP3uYg1BBmTo5P7bDApNTdAGCan77B1VJCTWl9vZged71xwkkkD9y3bsGZBaPlvlArk6T8IC6OdGESH99A+nITw4V5PF0KVDhScy5h+jSNVXV6MINt9TVhEFnsItJ+3Ff4ezdvanwH7xP4OfuAQbO0yFmFb65+0Dbj1I+AfN+5fxCNysjT/fetQIt8kPg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ESclIgUAhyEMriVMMZbXKbAx9ebTh8S2l0uwwlL7Nr+vMkNSVwPtqbCyyBJtj2JaDTL4eZUXOnd2uLiyJ+aEd7CPPQqjOEG/6s3CWpH10CVQCg2vCbwX5B/ctG065y/uxMf6rRHpTaqTj1r1AlneShJqt6up4AtHrgGAEXIKY30w9Kc/lD2rYsjmjNArUGRSKOOrz4e36V0PjtdIwAdi2IWvwSKrYGLO7iO2pHnoC2zATTVR2jaiwUi6M2cmUEIcYCHHtRYAWOZivVVxrmB1pJx8y78NJoTRusRKHosreyapzdD9/uV9CFlGo4ikQAzP7wWaPVzWbtngPYbUuJbkjA==
  • Authentication-results: esa6.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: Tue, 08 Mar 2022 10:13:15 +0000
  • Ironport-data: A9a23:iH5Pwq3zR5QMrMepTvbD5cVxkn2cJEfYwER7XKvMYLTBsI5bpzQEn WAWCmiGb6zZN2b8fIh/PI6/9UhXvsDXyoBhSQY5pC1hF35El5HIVI+TRqvS04J+DSFhoGZPt Zh2hgzodZhsJpPkjk7xdOCn9xGQ7InQLlbGILes1htZGEk1EE/NtTo5w7Rj2tUw0YDga++wk YiaT/P3aQfNNwFcagr424rbwP+4lK2v0N+wlgVWicFj5DcypVFMZH4sDfjZw0/DaptVBoaHq 9Prl9lVyI97EyAFUbtJmp6jGqEDryW70QKm0hK6UID66vROS7BbPg/W+5PwZG8O4whlkeydx /1Jlt+CURZ1HJbMleU3C0RVTRskNpBJreqvzXiX6aR/zmXDenrohf5vEFs3LcsT/eMf7WNmr KJCbmpXN1ba2rzwkOnTpupE36zPKOHxO4wSoDd4xCzxBvc6W5HTBa7N4Le02R9u254URKmPP 6L1bxJsfFffeg1+HGsUI80bh8mNnljweA9h/Qf9Sa0fvDGIkV0ZPKLWGMXRUsyHQ4NShEnwj nLL+SH1Dw8XMPSbyCGZ6TS8i+nXhyT5VYkOUrqi+ZZCglee22gSAx0+TkagrL+yjUvWZj5EA xVKoGx09/F0rRH1CImmN/GlnJKalho/GOhIArEY0wGAy4CMvgvHPDIPczEUPbTKq/QKbTAt0 1aImfbgCjpurKCZRBqhy1uEkd+hEXNLdDFfPEfoWSNAuoC++99r0nojW/4+SPbdszHjJd3nL 9lmRgAajq5bs8ME3r7TEbvv02P1/cihouLYC2zqsoOZAuFROdbNi2+AswGzARN8wGCxFAHpU J8swZT20Qz2JcvR/BFhuc1UdF1T296LMSfHnXlkFIQ7+jKm9haLJN4Mvm8hdBoya5ZZIlcFh XM/XysLv/e/21PwMcdKj3+ZUZx2ncAM6/y/PhwrUja+SscoL1LWlM2fTUWRw3rsgCARfVIXY v+mnTKXJS9CU8xPlWPuL89EiOND7n1ulAv7GMGgpzz6gOX2WZJgYepcWLd4Rrtit/3sTcS82 4s3CvZmPD0DCL2uOHeGq9VPRb3IRFBiba3LRwVsXrfrCiJtGX07Cu+XxrUkeod/mL9SmPuO9 Xa4MnK0AnKm7ZEbAW1mskxeVY4=
  • Ironport-hdrordr: A9a23:BXEa7q+Cl/QPWCpu2t5uk+E8db1zdoMgy1knxilNoENuHPBwxv rAoB1E73PJYVYqOE3Jmbi7Sc+9qFfnhONICO4qTMuftWjdyRGVxeRZjLcKrAeQfhEWmtQtsZ uINpIOd+EYbmIK/foSgjPIa+rIqePvmMvD6Ja8vhVQpENRGtpdBm9Ce3em+yZNNXB77PQCZf 2hDp0tnUvfRZ1bVLXxOlA1G8z44/HbnpPvZhALQzYh9Qm1lDutrJr3CQKR0BsyWy5Ghe5Kyx mJryXJooGY992rwB7V0GHeq7xQhdva09NGQOiBkNIcJDnAghuhIK5hR7qBljYop/zH0idhrP D85zMbe+hj4XLYeW+45TPrxgnbyT4rr0TvzFeJ6EGT1/DRdXYfMY5slIhZehzW5w4Lp9dnyp 9G2Gqfqt5+EQ7AtD6V3amHazha0m6P5VYym+8aiHJSFaEEbqVKkIAZ9ERJVL8dASPB7pw9Gu UGNrCS2B9vSyLbU5nlhBgt/DT1NU5DXCtuA3Jy9vB96gIm3UyQlCAjtYkidnRpzuNLd3AL3Z WBDk1SrsA9ciYnV9MPOA4/e7rDNoXse2OEDIvAGyWuKEk4U0i936Ifpo9Fo92XRA==
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Mon, Mar 07, 2022 at 02:53:32PM +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>

LGTM, just two questions.

> ---
> v2: Don't use (NOLOAD) for ELF; it has undocumented (and unhelpful)
>     behavior with GNU ld there. Also place .{sym,str,shstr}tab for LLVM
>     ld.
> ---
> 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.
> 
> --- 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
> +
>  $(TARGET): TMP = $(@D)/.$(@F).elf32
>  $(TARGET): $(TARGET)-syms $(efi-y) $(obj)/boot/mkelf32
>       $(obj)/boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TMP) 
> $(XEN_IMG_OFFSET) \
> @@ -146,7 +148,7 @@ $(TARGET)-syms: $(BASEDIR)/prelink.o $(o
>               >$(@D)/.$(@F).1.S
>       $(MAKE) $(build)=$(@D) $(@D)/.$(@F).1.o
>       $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds -N $< $(build_id_linker) \
> -         $(@D)/.$(@F).1.o -o $@
> +         $(orphan-handling-y) $(@D)/.$(@F).1.o -o $@
>       $(NM) -pa --format=sysv $(@D)/$(@F) \
>               | $(BASEDIR)/tools/symbols --all-symbols --xensyms --sysv 
> --sort \
>               >$(@D)/$(@F).map
> @@ -220,7 +222,7 @@ endif
>               | $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort 
> >$(@D)/.$(@F).1s.S
>       $(MAKE) $(build)=$(@D) .$(@F).1r.o .$(@F).1s.o
>       $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds -N $< \
> -                     $(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o $(note_file_option) 
> -o $@
> +           $(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o $(orphan-handling-y) 
> $(note_file_option) -o $@
>       $(NM) -pa --format=sysv $(@D)/$(@F) \
>               | $(BASEDIR)/tools/symbols --all-symbols --xensyms --sysv 
> --sort >$(@D)/$(@F).map
>       rm -f $(@D)/.$(@F).[0-9]* $(@D)/..$(@F).[0-9]*
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -12,6 +12,13 @@
>  #undef __XEN_VIRT_START
>  #define __XEN_VIRT_START __image_base__
>  #define DECL_SECTION(x) x :
> +/*
> + * Use the NOLOAD directive, despite currently ignored by (at least) GNU ld
> + * for PE output, in order to record that we'd prefer these sections to not
> + * be loaded into memory.
> + */
> +#define DECL_DEBUG(x, a) #x ALIGN(a) (NOLOAD) : { *(x) }
> +#define DECL_DEBUG2(x, y, a) #x ALIGN(a) (NOLOAD) : { *(x) *(y) }
>  
>  ENTRY(efi_start)
>  
> @@ -19,6 +26,8 @@ ENTRY(efi_start)
>  
>  #define FORMAT "elf64-x86-64"
>  #define DECL_SECTION(x) #x : AT(ADDR(#x) - __XEN_VIRT_START)
> +#define DECL_DEBUG(x, a) #x 0 : { *(x) }
> +#define DECL_DEBUG2(x, y, a) #x 0 : { *(x) *(y) }

Would it be helpful to place those in a 

>  
>  ENTRY(start_pa)
>  
> @@ -179,6 +188,13 @@ SECTIONS
>  #endif
>  #endif
>  
> +#ifndef EFI
> +  /* Retain these just for the purpose of possible analysis tools. */
> +  DECL_SECTION(.note) {
> +       *(.note.*)
> +  } PHDR(note) PHDR(text)

Wouldn't it be enough to place it in the note program header?

The buildid note is already placed in .rodata, so any remaining notes
don't need to be in a LOAD section?

> +#endif
> +
>    _erodata = .;
>  
>    . = ALIGN(SECTION_ALIGN);
> @@ -266,6 +282,32 @@ SECTIONS
>         __ctors_end = .;
>    } PHDR(text)
>  
> +#ifndef EFI
> +  /*
> +   * With --orphan-sections=warn (or =error) we need to handle certain linker
> +   * generated sections. These are all expected to be empty; respective
> +   * ASSERT()s can be found towards the end of this file.
> +   */
> +  DECL_SECTION(.got) {
> +       *(.got)
> +  } PHDR(text)
> +  DECL_SECTION(.got.plt) {
> +       *(.got.plt)
> +  } PHDR(text)
> +  DECL_SECTION(.igot.plt) {
> +       *(.igot.plt)
> +  } PHDR(text)
> +  DECL_SECTION(.iplt) {
> +       *(.iplt)
> +  } PHDR(text)
> +  DECL_SECTION(.plt) {
> +       *(.plt)
> +  } PHDR(text)
> +  DECL_SECTION(.rela) {
> +       *(.rela.*)
> +  } PHDR(text)

Why do you need to explicitly place those in the text program header?

Thanks, Roger.



 


Rackspace

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