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

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


  • To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • Date: Thu, 3 Mar 2022 20:02:10 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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=Urch2SAdWlJOjEgLahikV4ROS4eP8W7WNa29IKN8kIE=; b=i5PzIJ043IV6QKSy4b5lWeDj/0iFWvxV4xwBTGaw3ROC+Kmbbd3+BvvR/Rmy3lthw8zfyntZnTx6TPej2Dj0r504Jz0ycItdcmtADmxGqKbs3gtorQBqYTi4SoSktMm6f06J3l6Qq5ELhljE6EHOCx4e9PRvN4/yamoFL46ZSS4SMHFZykLpOWCWyNVZ0+HbGPDnmFCdctC+4vESvlL4N7u/izH+KCqgZORBf+/dnk9J1SxuTs7i+gUB+CLkPDlYpGlW1ILFonGkw2IrxamXLh6Vopjwk+RflJAnXQDODJ5P23NB4d3pXzGZ7yXS4YfDxTtyuIrY4oZevLUvQKVv1w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FJs+g+QI8Jd/uTy1c4QgzA3HxjXl/VRviPbWJuYhhPcYMmrNwiibGbHaNyozw+PgiPtdKEkFiTAU/M0NE9KEEYZ/21SAP1WJCkS3qTk7D3gfhSS8dEuOkXXl6VKo0mBTcJobzLYoVrvoMyj65WyNyCjk4kg6Lrs3q6xmt6MnYcrdTnZFj40nMuamYQu0KZBC1uynawtLpdYR/rinNpjWzgROVVmvTWAFI336OtlF1fE9pOlXm4vQyom1JeAMGe7qIGMO/7SoydzzAle3XyfY7Rq7MeMhbqc/LoegE3RWxScnMNw3bing0bsSTqhkx+nPXDw5VF5HIYf1qjtIZYFuZQ==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>
  • Delivery-date: Thu, 03 Mar 2022 20:02:25 +0000
  • Ironport-data: A9a23:jtuP7awdPSDB+6trNL56t+cvxirEfRIJ4+MujC+fZmUNrF6WrkUEz WMcXGDQaP7ba2TzctgnOYu/9xxU65DTxoRrHlE5/CAxQypGp/SeCIXCJC8cHc8zwu4v7q5Dx 59DAjUVBJlsFhcwnj/0bv656yMUOZigHtIQMsadUsxKbVIiGX9JZS5LwbZj2NYz2YPhWGthh PupyyHhEA79s9JLGjp8B5Kr8HuDa9yr5Vv0FnRnDRx6lAe2e0s9VfrzFonoR5fMeaFGH/bSe gr25OrRElU1XfsaIojNfr7TKiXmS1NJVOSEoiI+t6OK2nCuqsGuu0qS2TV1hUp/0l20c95NJ NpliKa1ezgoYZDwv/00fwJ9Sg1VAIMaweqSSZS/mZT7I0zudnLtx7NlDV0sPJ1e8eFyaY1M3 aVGcnZXNEnF3r/ohuLgIgVvrp1LwM3DFYUToHx/ixreCu4rW8vrSKTW/95Imjw3g6iiGN6AO pZDM2o2MXwsZTV1JgkeLpI/pNzwrXLTLm1K+FOPtYQOtj27IAtZj+G2bYu9lsaxbdpRtlaVo CTB5WuRKgEXMpmTxCSI9lqoh/TThmXrVYQKDrq6+/V2xlqJyQQ7ChcbSF+6qvmRkVOlVpRUL El8x8Y1hfFsrgrxFIC7BkDm5i7f1vIBZzZOO9AA7TOyy/Xp3yGAL0Qfa2dtQ+EI6PZjEFTGy WS1t9/uADVutpicRnSc6qqYoFuOBMQFEYMRTXRaFFVYurEPtKl210uSFYg7TMZZm/WoQWmY/ tyckMQpa1z/Z+Yv3r7zw13IiinESnPhHl9svVW/so5IA2pEiG+Zi26AtACzARVodt/xory9U J4swZL2AAcmV8zlqcB1aL9RdIxFHt7cWNEmvXZhHoM66xOm8GO5cIZb7VlWfRk1bJxYJ2O4O xCO4Gu9AaO/2lPwN8ebhKrrVqwXIVXIT4y5Bpg4kPIUCnSOSON31H43PhPBt4wcuEMtjbs+K f+mnTWEVh4n5VBc5GPuHY81iOZzrghnnD+7bcmin3yPjOrPDFbIGOxtGAbfMYgEAFas/Vy9H yB3bJDRlX2ykYTWP0HqzGLkBQtSfChjWMuv8JQ/myzqClMOJVzNwsT5mNsJU4dkg75UhqHP+ HS8UVVf013xmTvMLgDiV5ypQOiHsUpXxZ7jARERAA==
  • Ironport-hdrordr: A9a23:iv6UIazbDeuljpMd1Z0GKrPwKL1zdoMgy1knxilNoHtuA6ulfq GV7ZAmPHrP4wr5N0tNpTntAsa9qBDnlaKdg7N+AV7KZmCP0gaVxepZjLfK8nnNHDD/6/4Y9Y oISdkaNDQoNykYsS8t2njbL+od
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHYLUom+7MvssZr9kajAcxWuiy9JqyuGI0A
  • Thread-topic: [Regression] [PATCH] x86: fold sections in final binaries

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)

~Andrew

 


Rackspace

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