|
[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:
> On 22/03/2022 08:02, Michal Orzel wrote:
>> --- 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?
The identifier may now be somewhat misleading, yes - it has always meant
"linking a native EFI (i.e. PE/COFF) binary". The equivalence "EFI binary"
== "EFI support" has long been lost.
>> +/*
>> + * 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?
Given the above explanation I think it's clear that only one of the
two may be used at a time: ELF_DETAILS_SECTIONS when linking an ELF
binary and DISCARD_EFI_SECTIONS when linking a PE/COFF binary.
Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |