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

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


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 1 Mar 2022 15:06:30 +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=hORdoKxuHhXm3Z9OxT65NOFrf0TCcz7XNSLSOaspVgQ=; b=hyRQ9KOszQLLT/nDhzeA6m+ACOvRL4rdiclDFPPKNmZQVFsDeZa8k8nFKF9X/1K3I1mHnRcoCstVYI/jw+z6lfpJlK1xSIHr3UucmfGF5X5ssv6X6UZ8I8yxAFiXFNafmRVHGE3rvcH93L0p4pYFyNi3fjqamAfuWKQxDDAJ3KCmrdmF9NmkSZHTFzEedxoCcAL7yxVMEOXr10I/LJedXK9GMujHZasJsnF7HdqWhm4aj07pHGOFmSFVIZIdVfkmPCFeyol7unN9JUgDNchmycdwm45L0u7/c/Z8XNI4K5yR2ddvbHFp3S+UmHCyjupTFzKn/haXqXxNwyk+SqATsg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a/xaQ/5fLvveAxVIaaUNTZk/7aIO8bb+YK/tm1JKY4D+0XkvX8aqYoPpYC/40vt8Dz8FwiAVqXlLgr7FbRC5XVpRKYbDRrv2fH50JHZWWYNcDCOESd87qCqY0A52hnPUtu8OcwzQbCMQ5nKGHtOGfWJgW5IZoA53Wk/JKGArtH1ztOcFcFnnSqUaiWAVHWQDvViR0PhinLRTVa/q0NnutR/IbzSANtHqS9U6fAfLx+tHjFh68Mtr3AEx85RbcRF/k2pje7IdO5//XInNfXgFMInJXn7NrzlnfZ5uTFS69MWmK/M7wMCyzCeRXvZFh9323x0zP2xhJ9MBXFZMs9U7jw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Tue, 01 Mar 2022 14:06:43 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 01.03.2022 14:43, Roger Pau Monné wrote:
> On Tue, Mar 01, 2022 at 09:55:32AM +0100, 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.
> 
> Should we also use --orphan-handling=warn as to recognize orphaned
> sections and attempt place them? We have now detected this because of
> the 16Mb limit, but if we remove that check that we could end up
> carrying a non-trivial amount of 2Mb aligned unhandled regions.

Yes, I guess we should use this option. See below.

>> 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.
> 
> I've found some (old) documentation where it does also mention ECOFF
> and XCOFF apart from a.out:
> 
> "When linking object file formats which do not support arbitrary
> sections, such as ECOFF and XCOFF, the linker will automatically
> recognize C++ global constructors and destructors by name. For these
> object file formats, the CONSTRUCTORS command tells the linker where
> this information should be placed."
> 
> I guess we can get rid of it.

I've taken note to make yet another patch.

> The patch LGTM:
> 
> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

Thanks.

> With the possible addition of --orphan-handling=warn.

As above: I agree we should make use of the option, but I don't think
this should be squashed in here. The option appeared in 2.26, so with
the current documented binutils baseline we'll need to probe for its
availability. I'd therefore prefer to make this a separate change,
and I've taken respective note as well.

Jan




 


Rackspace

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