[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: Julien Grall <julien@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 29 Mar 2022 12:37:23 +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=39ONaxOkD0qny6Fxuyogw1JKeMfuDg3BuyR738VenmQ=; b=d0edbJB/ugE8BjG/U3YskOZttsdfKzIgyhSDCvl3OpMZXPxkHFb5OwwdO5sm+XX2tUMJgphN4A1V+tNRQ7V9LoTZRfVprCNH6+BWr1hn7ncoMNkl3DsIcmzj0sZNgiA44wNxVREEdIevmwKBYHmakaPRTKds39xwdH+X9rN0szL8SaFO7u7W4Xj2BVCjiWVVk5dB2vO+XXOxBq+OQG8rsbExw6zyxHWnBhAXpdK8gw54j7T+42UmSP2ArqtTWAzfdkYaD60xRsez/uOpNKpgSmcEHdtce52JA7mt3kqjqgc0Tu/oEPrD8OC5kfd2yVdWwhV348JYz7AjwIXag663Ww==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GLMsHg0V+02M7t/KA1q+A3K+LSswpGwFMThXf3ApiJg2nSbAvTFirO2Jxtc933MArq7vlKZrcqAJqOU0IWc0ZJrsqmBeK3QO1U8GxD4QRCMYI4NZaVY1B/uqmvcOGf8Ve3HB6pGQLKT/Sg2BW6bcQp0pYCsjiBc9nABOYLva9uT+P5mzswI13egSuDJvJCl7MU7WQtXWQjevG+Vd768DjLEdQCbWGzT7cqzsxd90zbgvZ6D4w1YFONHueuNkW8nY/V92rhNfANKNlF8vV6EGt+z9jDSv22SDIZd3DF9p8uaHzNrcRVpGPb+arHOurk3ciJ+pkUZloMsL+ZRXkWCoJA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, 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>, Michal Orzel <michal.orzel@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 29 Mar 2022 10:37:36 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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




 


Rackspace

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