[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 29.03.2022 11:54, Julien Grall wrote:
> Hi,
> 
> On 22/03/2022 08:02, Michal Orzel wrote:
>> Populate header file xen.lds.h with the first portion of macros storing
>> constructs common to x86 and arm linker scripts. Replace the original
>> constructs with these helpers.
>>
>> No functional improvements to x86 linker script.
>>
>> Making use of common macros improves arm linker script with:
>> -explicit list of debug sections that otherwise are seen as "orphans"
> 
> NIT: This is a bit confusing to see no space after -. Can you add one?
> 
Ok.

> I would also recommend to start with (soft)tab to make clearer this is a list.
> 
> Same goes for the  other use below.
> 
Ok.

> 
>> by the linker. This will allow to fix issues after enabling linker
>> option --orphan-handling one day
>> -extended list of discarded section to include: .discard, desctructors
> 
> Typo: s/desctructors/destructors/
> 
Ok.

>> related sections, .fini_array which can reference .text.exit
>> -sections not related to debugging that are placed by ld.lld.
>> Even though Xen on arm compilation with LLVM support is not ready yet,
> 
> Building natively Xen on Arm with Clang works. So do you mean you using LLD?
> 
I mean using the LLVM replacements not only for CC + supporting 
cross-compilation.
As for the linker, Xen sets llvm-ld which is very very old and in fact README 
states
LLVM 3.5 or later but llvm-ld was removed before that. Thus IMO support for 
LLVM on arm
is not ready yet.

> NIT: Also, from the formatting it is not clear that the second sentence is 
> part of the last item. How about removing the newline just after the first 
> sentence?
> 
Ok.

>> these sections do not cause problem to GNU ld.
>>
>> Please note that this patch does not aim to perform the full sync up
>> between the linker scripts. It creates a base for further work.
>>
>> Signed-off-by: Michal Orzel <michal.orzel@xxxxxxx>
> 
> [...]
> 
>> diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
>> index dd292fa7dc..ad1d199021 100644
>> --- 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
> 
> AFAIK, we don't define EFI on Arm (just CONFIG_EFI). Yet we do support EFI on 
> arm64.
> 
> As this #ifdef is now in generic code, can you explain how this is meant to 
> be used?
> 
As we do not define EFI on arm, all the stuff protected by #ifdef EFI is x86 
specific.

>> +/*
>> + * 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                      \
>> +  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) }   \
> 
> This is a bit confusing. Here you seem to use the section .comment. But...
> 
>> +  .symtab 0 : { *(.symtab) }     \
>> +  .strtab 0 : { *(.strtab) }     \
>> +  .shstrtab 0 : { *(.shstrtab) }
>> +
>> +#ifdef EFI
>> +#define DISCARD_EFI_SECTIONS \
>> +       *(.comment)   \
> 
> ... here you will discard it if EFI is set. Which one take precedence if the 
> caller use both ELF_DETAILS_SECTIONS and DISCARD_EFI_SECTION?
> 
ELF_DETAILS_SECTIONS is protected by #ifndef EFI and DISCARD_EFI_SECTION by 
#ifdef EFI
so the caller cannot use both ELF_DETAILS_SECTIONS and DISCARD_EFI_SECTION.

> Also, can you explain why we need to drop those sections when EFI is set?
> 
This is related to x86. Please see the commit: 
7844f90abd551f6d5cd9b670b5ed8a4683258a21

>> +       *(.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);             \
>> +       __paramhypfs_start = .;   \
>> +       *(.data.paramhypfs)       \
>> +       __paramhypfs_end = .;
>> +
>> +#define LOCK_PROFILE_DATA        \
>> +       . = ALIGN(POINTER_ALIGN); \
>> +       __lock_profile_start = .; \
>> +       *(.lockprofile.data)      \
>> +       __lock_profile_end = .;
>> +
>>   #endif /* __XEN_LDS_H__ */
> 
> Cheers,
> 

Cheers,
Michal



 


Rackspace

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