|
[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
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |