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
