Linking debug info takes time, especially for xen.efi. At the same time
symbol table contents aren't affected by presence / absence of debug info
in the linked binaries (the ELF and COFF symbol tables would have extra
section symbols, but tools/symbols omits those anyway).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
The main speed gain is from xen.efi linking. Therefore I'm not even sure
if this wants mirroring to the other targets, where only xen-syms is
produced. It would mainly be some transient space saving there. (It would
perhaps want retaining when the linking steps are moved to common code.)
Thoughts?
On the system I measured this on, "real" time went down from 4.9s to 3.9s,
while "user" time went from 7.8s to 6.8s (all approximate values of
course, as there naturally is a bit of variance, and all for full
incremental builds with no other changes, i.e. mainly the final linking
steps getting carried out for the common/version.o change).
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -127,13 +127,13 @@ CFLAGS-$(XEN_BUILD_EFI) += -DXEN_BUILD_E
$(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) \
+ $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) --strip-debug \
$(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) \
+ $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) --strip-debug \
$(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) \
@@ -205,7 +205,7 @@ endif
$(MAKE) $(build)=$(@D) .$(@F).0s.o
$(foreach base, $(VIRT_BASE) $(ALT_BASE), \
$(LD) $(call EFI_LDFLAGS,$(base)) -T $(obj)/efi.lds $< $(relocs-dummy) \
- $(dot-target).0s.o $(note_file_option) \
+ $(dot-target).0s.o $(note_file_option) --strip-debug \
-o $(dot-target).$(base).0 &&) :
$(MKRELOC) $(foreach base,$(VIRT_BASE) $(ALT_BASE),$(dot-target).$(base).0) \
> $(dot-target).1r.S
@@ -215,7 +215,7 @@ endif
> $(dot-target).1s.S
$(MAKE) $(build)=$(@D) .$(@F).1r.o .$(@F).1s.o
$(foreach base, $(VIRT_BASE) $(ALT_BASE), \
- $(LD) $(call EFI_LDFLAGS,$(base)) -T $(obj)/efi.lds $< \
+ $(LD) $(call EFI_LDFLAGS,$(base)) -T $(obj)/efi.lds $< --strip-debug \
$(dot-target).1r.o $(dot-target).1s.o $(note_file_option) \
-o $(dot-target).$(base).1 &&) :
$(MKRELOC) $(foreach base,$(VIRT_BASE) $(ALT_BASE),$(dot-target).$(base).1) \On 20/05/2026 1:11 pm, Jan Beulich wrote: > Linking debug info takes time, especially for xen.efi. At the same time > symbol table contents aren't affected by presence / absence of debug info > in the linked binaries (the ELF and COFF symbol tables would have extra > section symbols, but tools/symbols omits those anyway). > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > --- > The main speed gain is from xen.efi linking. Therefore I'm not even sure > if this wants mirroring to the other targets, where only xen-syms is > produced. It would mainly be some transient space saving there. (It would > perhaps want retaining when the linking steps are moved to common code.) > Thoughts? > > On the system I measured this on, "real" time went down from 4.9s to 3.9s, > while "user" time went from 7.8s to 6.8s (all approximate values of > course, as there naturally is a bit of variance, and all for full > incremental builds with no other changes, i.e. mainly the final linking > steps getting carried out for the common/version.o change). If it saves time, then good; this will make an improvement to my dev cycle. How does it fair on Ubuntu 16.04, where we've other known issues about the debug symbols appearing to be corrupt? It would be nice to be consistent across the board. If we're going to make linking common soon, then it's probably fine, but this does risk becoming yet another mysterious difference. ~Andrew
On 20.05.2026 14:51, Andrew Cooper wrote: > On 20/05/2026 1:11 pm, Jan Beulich wrote: >> Linking debug info takes time, especially for xen.efi. At the same time >> symbol table contents aren't affected by presence / absence of debug info >> in the linked binaries (the ELF and COFF symbol tables would have extra >> section symbols, but tools/symbols omits those anyway). >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> >> --- >> The main speed gain is from xen.efi linking. Therefore I'm not even sure >> if this wants mirroring to the other targets, where only xen-syms is >> produced. It would mainly be some transient space saving there. (It would >> perhaps want retaining when the linking steps are moved to common code.) >> Thoughts? >> >> On the system I measured this on, "real" time went down from 4.9s to 3.9s, >> while "user" time went from 7.8s to 6.8s (all approximate values of >> course, as there naturally is a bit of variance, and all for full >> incremental builds with no other changes, i.e. mainly the final linking >> steps getting carried out for the common/version.o change). > > If it saves time, then good; this will make an improvement to my dev > cycle. How does it fair on Ubuntu 16.04, where we've other known issues > about the debug symbols appearing to be corrupt? All builds are green in https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/14480259043. > It would be nice to be consistent across the board. If we're going to > make linking common soon, then it's probably fine, but this does risk > becoming yet another mysterious difference. Well, I can add --strip-debug everywhere, but it feels somewhat unjustified. Except if we take the disk space / I/O reduction into account. Jan
On 21/05/2026 11:23 am, Jan Beulich wrote: > On 20.05.2026 14:51, Andrew Cooper wrote: >> On 20/05/2026 1:11 pm, Jan Beulich wrote: >>> Linking debug info takes time, especially for xen.efi. At the same time >>> symbol table contents aren't affected by presence / absence of debug info >>> in the linked binaries (the ELF and COFF symbol tables would have extra >>> section symbols, but tools/symbols omits those anyway). >>> >>> Signed-off-by: Jan Beulich <jbeulich@suse.com> >>> --- >>> The main speed gain is from xen.efi linking. Therefore I'm not even sure >>> if this wants mirroring to the other targets, where only xen-syms is >>> produced. It would mainly be some transient space saving there. (It would >>> perhaps want retaining when the linking steps are moved to common code.) >>> Thoughts? >>> >>> On the system I measured this on, "real" time went down from 4.9s to 3.9s, >>> while "user" time went from 7.8s to 6.8s (all approximate values of >>> course, as there naturally is a bit of variance, and all for full >>> incremental builds with no other changes, i.e. mainly the final linking >>> steps getting carried out for the common/version.o change). >> If it saves time, then good; this will make an improvement to my dev >> cycle. How does it fair on Ubuntu 16.04, where we've other known issues >> about the debug symbols appearing to be corrupt? > All builds are green in > https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/14480259043. Ok. Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> > >> It would be nice to be consistent across the board. If we're going to >> make linking common soon, then it's probably fine, but this does risk >> becoming yet another mysterious difference. > Well, I can add --strip-debug everywhere, but it feels somewhat unjustified. > Except if we take the disk space / I/O reduction into account. It's mainly a guess on how long until we unify. ~Andrew
© 2016 - 2026 Red Hat, Inc.