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

[Jan Beulich <jbeulich@xxxxxxxx>]

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?

>  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.

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.

Jan