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

Re: [PATCH v2 2/2] xen: Populate xen.lds.h and make use of its macros


  • To: Michal Orzel <michal.orzel@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 29 Mar 2022 11:22:25 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=oPQZP3cFKx3Szc0xvJHHNEJ6aKA3QFDHjlIcHFreOgQ=; b=OYevLuhYT43aProv/trncIda1xkYZQps7d0w6rnC1hcEsCx8toAsp4fwAaxvP+qiUcHXG/fMtdsTvlIBugC2Zq/1lnHyeA8GAvUunXqr6kr0/YgPok6FP+C/Uu3rBOglB+TaifKr2aSXdlqhu2mNTcjkZIYdHNy2Ysv2WxjgzTsVTw2j13Rc+FyOkZEYfod8tImlPNGurb+18v7xjPLeZ90U953fOugsdtdZ8yEpXUxfYU7MmKkVQ4dvFctmgWDBEQdKNrIUCbKuDc3hKSHk8KsP1VC/XCic6OtD+khrTtjZHWcUoFqrNPHNqh4Ohqtz0IJH76IYCLK8IudpFIJk1Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Eq8AzoJd7sxJQ5TsKGQTuPto0YDKpYPb+SmqSj6Cyy00CgJtcwQ0aR2obvZ7tz8XrfRcByn5s39nwoGElpGny45NpqBQdHzg0qdQUBx04e6XRKMXVZ90mKa+JETMvtp1QsfaORmzMTBkhXTWuDQJgSkEE5ZFbXjBaGCyJY6K9v8xR7oK+iZLTFhxA60AVXs0eh/ex5bFeM1sVoUe9RYdYneFoWOTeMJJuFcTNZo5x1pNNB5+WdeagRW4wIDca7nGoCLND0bT46adF3NNCqGgfxjMqLGrY6JIvXByDS24IC3Xdf1q23nRFIKKR8QaMXmtHSKLAGoiJYnBTPncEWEamA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 29 Mar 2022 09:22:40 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 22.03.2022 09:02, Michal Orzel wrote:
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -69,10 +69,7 @@ SECTIONS
>         __proc_info_end = .;
>  
>  #ifdef CONFIG_HAS_VPCI
> -       . = ALIGN(POINTER_ALIGN);
> -       __start_vpci_array = .;
> -       *(SORT(.data.vpci.*))
> -       __end_vpci_array = .;
> +       VPCI_ARRAY
>  #endif

Here and elsewhere I think the #ifdef should move as well, or to be
precise VPCI_ARRAY (in the specific case here) should simply expand to
nothing when CONFIG_HAS_VPCI is not defined.

> @@ -222,22 +213,18 @@ SECTIONS
>    /* Section for the device tree blob (if any). */
>    .dtb : { *(.dtb) } :text
>  
> +  /*
> +   * Explicitly list debug sections, to avoid these sections being viewed as
> +   * "orphan" by the linker.
> +   */
> +  DWARF_DEBUG_SECTIONS

Considering the comment, perhaps better to move ...

>    /* Sections to be discarded */
> -  /DISCARD/ : {
> -       *(.exit.text)
> -       *(.exit.data)
> -       *(.exitcall.exit)
> -       *(.eh_frame)
> -  }
> +  DISCARD_SECTIONS
>  
>    /* Stabs debugging sections.  */
> -  .stab 0 : { *(.stab) }
> -  .stabstr 0 : { *(.stabstr) }
> -  .stab.excl 0 : { *(.stab.excl) }
> -  .stab.exclstr 0 : { *(.stab.exclstr) }
> -  .stab.index 0 : { *(.stab.index) }
> -  .stab.indexstr 0 : { *(.stab.indexstr) }
> -  .comment 0 : { *(.comment) }
> +  STABS_DEBUG_SECTIONS

... this up there?

> --- a/xen/include/xen/xen.lds.h
> +++ b/xen/include/xen/xen.lds.h
> @@ -5,4 +5,104 @@
>   * Common macros to be used in architecture specific linker scripts.
>   */
>  
> +/* Macros to declare debug sections. */
> +#ifdef EFI
> +/*
> + * 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) }
> +#else
> +#define DECL_DEBUG(x, a) #x 0 : { *(x) }
> +#define DECL_DEBUG2(x, y, a) #x 0 : { *(x) *(y) }
> +#endif
> +
> +/* DWARF debug sections. */
> +#define DWARF_DEBUG_SECTIONS                      \

May I suggest to call this DWARF2_DEBUG_SECTIONS, to make clear no
Dwarf1 section is included here (and we also don't mean to support
such debug info)?

> +  DECL_DEBUG(.debug_abbrev, 1)                    \
> +  DECL_DEBUG2(.debug_info, .gnu.linkonce.wi.*, 1) \
> +  DECL_DEBUG(.debug_types, 1)                     \
> +  DECL_DEBUG(.debug_str, 1)                       \
> +  DECL_DEBUG2(.debug_line, .debug_line.*, 1)      \
> +  DECL_DEBUG(.debug_line_str, 1)                  \
> +  DECL_DEBUG(.debug_names, 4)                     \
> +  DECL_DEBUG(.debug_frame, 4)                     \
> +  DECL_DEBUG(.debug_loc, 1)                       \
> +  DECL_DEBUG(.debug_loclists, 4)                  \
> +  DECL_DEBUG(.debug_macinfo, 1)                   \
> +  DECL_DEBUG(.debug_macro, 1)                     \
> +  DECL_DEBUG(.debug_ranges, 8)                    \
> +  DECL_DEBUG(.debug_rnglists, 4)                  \
> +  DECL_DEBUG(.debug_addr, 8)                      \
> +  DECL_DEBUG(.debug_aranges, 1)                   \
> +  DECL_DEBUG(.debug_pubnames, 1)                  \
> +  DECL_DEBUG(.debug_pubtypes, 1)
> +
> +/* Stabs debug sections. */
> +#define STABS_DEBUG_SECTIONS                 \
> +  .stab 0 : { *(.stab) }                     \
> +  .stabstr 0 : { *(.stabstr) }               \
> +  .stab.excl 0 : { *(.stab.excl) }           \
> +  .stab.exclstr 0 : { *(.stab.exclstr) }     \
> +  .stab.index 0 : { *(.stab.index) }         \
> +  .stab.indexstr 0 : { *(.stab.indexstr) }
> +
> +/*
> + * Required sections not related to debugging.
> + *
> + * LLVM ld also wants .symtab, .strtab, and .shstrtab placed. These look to
> + * be benign to GNU ld, so we can have them here unconditionally.
> + */
> +#define ELF_DETAILS_SECTIONS     \
> +  .comment 0 : { *(.comment) }   \
> +  .symtab 0 : { *(.symtab) }     \
> +  .strtab 0 : { *(.strtab) }     \
> +  .shstrtab 0 : { *(.shstrtab) }
> +
> +#ifdef EFI
> +#define DISCARD_EFI_SECTIONS \
> +       *(.comment)   \
> +       *(.comment.*) \
> +       *(.note.*)
> +#else
> +#define DISCARD_EFI_SECTIONS
> +#endif
> +
> +/* Sections to be discarded. */
> +#define DISCARD_SECTIONS     \
> +  /DISCARD/ : {              \
> +       *(.text.exit)         \
> +       *(.exit.text)         \
> +       *(.exit.data)         \
> +       *(.exitcall.exit)     \
> +       *(.discard)           \
> +       *(.discard.*)         \
> +       *(.eh_frame)          \
> +       *(.dtors)             \
> +       *(.dtors.*)           \
> +       *(.fini_array)        \
> +       *(.fini_array.*)      \
> +       DISCARD_EFI_SECTIONS  \
> +  }
> +
> +#define VPCI_ARRAY               \
> +       . = ALIGN(POINTER_ALIGN); \
> +       __start_vpci_array = .;   \
> +       *(SORT(.data.vpci.*))     \
> +       __end_vpci_array = .;
> +
> +#define HYPFS_PARAM              \
> +       . = ALIGN(8);             \

Since you're generalizing this, you mean POINTER_ALIGN here, not 8.

> +       __paramhypfs_start = .;   \
> +       *(.data.paramhypfs)       \
> +       __paramhypfs_end = .;
> +
> +#define LOCK_PROFILE_DATA        \
> +       . = ALIGN(POINTER_ALIGN); \
> +       __lock_profile_start = .; \
> +       *(.lockprofile.data)      \
> +       __lock_profile_end = .;

While for *_SECTIONS I don't care as much, for these last three items
I think it would be good if we (maybe just informally) established an
ordering rule, such that we can ask further additions here to not occur
randomly. Once we've grown a few more of these, this would also help
quickly locating the perhaps just one construct of interest when
looking up things. Personally I think the only sensible ordering
criteria is the name of the construct being defined. This could be
mentioned in a comment ahead of them, and that comment would then at
the same time serve as separator between *_SECTIONS and any constructs
also defining (enclosing) symbols.

Jan




 


Rackspace

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