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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, Mar 01, 2022 at 03:06:30PM +0100, Jan Beulich wrote:
> 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.

I didn't check when it first appeared. I'm fine with a separate
change.

Thanks, Roger.