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

Re: [Regression] [PATCH] x86: fold sections in final binaries


  • To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 4 Mar 2022 08:29:42 +0100
  • 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=Vob/TRDzpFKLurlcs5DJ56sShHWhgC6Etwn80wNOGWo=; b=i6eQj2ob+XaoLCXBpPdubUynB43bbIgoLBcp6Wup3enS3n2GmPSLQe/3dNW6pGc4nAT71QlNgJkGfBRkZKvsP0wt+gFTbBIns9coXAD7deRWmoRAjpcPzdxB52Xvx5MMPXsOslfjePQoAOgkG5AH5dnIFTrgBcBj7O2RfrvfEesSfmaAHptv5kfeFTTA94jT+U/Z6eYXRk/JOJI2Q8mkqueJcyAzqD+an4458BhRknlSmlV6YKIL5JN+SeKN8sTiwdzPz2cDfluDhPwRznEw7Tbp7r3YSJqY/075SJYqad2leu/28s7QQVXo403BphPSGxo3rj2CAsNueCDSdnAY0Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LwTzS2SdKxLfN3rWLPInEoeTYkI9/tHc3Mcx779lI+og0xpNNtUox0BJQAwwPgUmg1XIWpUjuHJIourVO3TcLlE4rwL5aEL2ewfvv2589vI8otoKt8qXezYwma+WX1kE4YaykCOeSuf7xpmZ8A5TVbHYo4ggJvZMpwgVaUN7hQSyEGKaSFsglpW6JnNXtwekYWtk+uM5LIgeE/9mZaZDKBYMX/H33vPnVHjIpOKwuclAsjvKJQmQgFo4WFoaLmvexPfNm0AOu5GBo64GHMcqYVmrxbBVuhtozzDHhjJo0UduRf+nXLowOlKSsOk7ZQXe/qRh6DN9XSnIJUINnbWxag==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 04 Mar 2022 07:29:52 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 03.03.2022 21:02, Andrew Cooper wrote:
> On 01/03/2022 08:55, Jan Beulich wrote:
>> Especially when linking a PE binary (xen.efi), standalone output
>> sections are expensive: Often the linker will align the subsequent one
>> on the section alignment boundary (2Mb) when the linker script doesn't
>> otherwise place it. (I haven't been able to derive from observed
>> behavior under what conditions it would not do so.)
>>
>> With gcov enabled (and with gcc11) I'm observing enough sections that,
>> as of quite recently, the resulting image doesn't fit in 16Mb anymore,
>> failing the final ASSERT() in the linker script. (That assertion is
>> slated to go away, but that's a separate change.)
>>
>> Any destructor related sections can be discarded, as we never "exit"
>> the hypervisor. This includes .text.exit, which is referenced from
>> .dtors.*. Constructor related sections need to all be taken care of, not
>> just those with historically used names: .ctors.* and .text.startup is
>> what gcc11 populates. While there re-arrange ordering / sorting to match
>> that used by the linker provided scripts.
>>
>> Finally, for xen.efi only, also discard .note.gnu.*. These are
>> meaningless in a PE binary. Quite likely, while not meaningless there,
>> the section is also of no use in ELF, but keep it there for now.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> TBD: We also use CONSTRUCTORS for an unknown reason. Documentation for
>>      ld is quite clear that this is an a.out-only construct.
>>      Implementation doesn't look to fully match this for ELF, but I'd
>>      nevertheless be inclined to remove its use.
>>
>> --- a/xen/arch/x86/xen.lds.S
>> +++ b/xen/arch/x86/xen.lds.S
>> @@ -194,6 +194,7 @@ SECTIONS
>>  #endif
>>         _sinittext = .;
>>         *(.init.text)
>> +       *(.text.startup)
>>         _einittext = .;
>>         /*
>>          * Here are the replacement instructions. The linker sticks them
>> @@ -258,9 +259,10 @@ SECTIONS
>>  
>>         . = ALIGN(8);
>>         __ctors_start = .;
>> -       *(.ctors)
>> +       *(SORT_BY_INIT_PRIORITY(.init_array.*))
>> +       *(SORT_BY_INIT_PRIORITY(.ctors.*))
>>         *(.init_array)
>> -       *(SORT(.init_array.*))
>> +       *(.ctors)
>>         __ctors_end = .;
>>    } PHDR(text)
>>  
>> @@ -404,16 +406,20 @@ SECTIONS
>>  
>>    /* Sections to be discarded */
>>    /DISCARD/ : {
>> +       *(.text.exit)
>>         *(.exit.text)
>>         *(.exit.data)
>>         *(.exitcall.exit)
>>         *(.discard)
>>         *(.discard.*)
>>         *(.eh_frame)
>> +       *(.dtors)
>> +       *(.dtors.*)
>>  #ifdef EFI
>>         *(.comment)
>>         *(.comment.*)
>>         *(.note.Xen)
>> +       *(.note.gnu.*)
>>  #endif
>>    }
> 
> This breaks reliably in Gitlab CI.
> 
> https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/2159059956 (gcc 11)

Hmm, I wonder why I'm not seeing this locally. The lack of mentioning of
.fini_array in the linker script struck me as odd already before. I can
easily make a patch to add those sections to the script, but I'd first
like to understand why I'm seeing gcc11 use .ctors / .dtors while here
it's .init_array / .fini_array.

Jan




 


Rackspace

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