Re: [PATCH] RFC: xen/x86: Enable --gc-sections

[Jason Andryuk <jason.andryuk@xxxxxxx>]

On 2025-12-08 03:56, Jan Beulich wrote:
> On 05.12.2025 23:28, Jason Andryuk wrote:
> > When linking to create xen-syms, add --gc-sections to garbage collect
> > unused stuff.
> What about xen.efi?
I tried briefly and it fails to link.  The GCC manual says it is 
considered experimental for PE and COFF.
I just added into EFI_LDFLAGS:
  CC      .xen.efi.0s.o
ld -mi386pep --no-warn-rwx-segments --subsystem=10 
--enable-long-section-names --disable-high-entropy-va --dynamicbase 
--image-base=0xffff82d040000000 --stack=0,0 --heap=0,0 
--section-alignment=0x200000 --file-alignment=0x20 
--major-image-version=4 --minor-image-version=22 --major-os-version=2 
--minor-os-version=0 --major-subsystem-version=2 
--minor-subsystem-version=0 --gc-sections --print-gc-sections 
--build-id=sha1 -T arch/x86/efi.lds prelink.o  ./.xen.efi.0s.o -b 
pe-x86-64 arch/x86/efi/buildid.o -o ./.xen.efi.0xffff82d040000000.0 && :
ld: kexec_reloc is too large
ld: kexec_reloc is too large
ld: 
prelink.o:/home/jandryuk/xen/xen/arch/x86/boot/head.S:60:(.text.header+0x48): 
undefined reference to `start'

> >   Relies on CONFIG_CC_SPLIT_SECTIONS
> Yet still ...
>
> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -137,18 +137,21 @@ $(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
> >         $(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S
> >         $(MAKE) $(build)=$(@D) $(dot-target).0.o
> >         $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
> > +             --gc-sections \
> ... you pass the option unconditionally. Which may be fine from a functional
> perspective (little if anything will be saved), but besides being a little
> inconsistent with the description I also wonder whether the option won't have
> unwanted side effects (longer linking time, bigger working set).
>
> >               $(dot-target).0.o -o $(dot-target).0
> >         $(NM) -pa --format=sysv $(dot-target).0 \
> >                 | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
> >                 > $(dot-target).1.S
> >         $(MAKE) $(build)=$(@D) $(dot-target).1.o
> >         $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
> > +             --gc-sections \
> >             $(dot-target).1.o -o $(dot-target).1
> >         $(NM) -pa --format=sysv $(dot-target).1 \
> >                 | $(objtree)/tools/symbols $(all_symbols) --sysv --sort 
> > $(syms-warn-dup-y) \
> >                 > $(dot-target).2.S
> >         $(MAKE) $(build)=$(@D) $(dot-target).2.o
> >         $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
> > +             --gc-sections \
> >             $(orphan-handling-y) $(dot-target).2.o -o $@
> >         $(NM) -pa --format=sysv $@ \
> Rather than having to alter three locations (plus another three for xen.efi,
> plus another three for every other architecture that would want to follow
> suit), should we perhaps introduce $(XEN_FINAL_LDFLAGS) or some such? That
> could then have --gc-sections conditionally upon CONFIG_CC_SPLIT_SECTIONS.
Yes, I thought something like thiat would be better after posting.

> I further wonder whether the use of the option wouldn't want gating by its
> own Kconfig control (dependent upon CC_SPLIT_SECTIONS). If nothing else than
> to have an easy workaround if either we had a usage bug (e.g. a missing
> KEEP() somewhere in a linker script) or there was a related bug in the
> linker that we end up being affected by.
Makes sense.

Thanks,
Jason