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 <[email protected]> > >> --- > >> 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é <[email protected]> > > 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.
