On 20.11.2025 14:59, Frediano Ziglio wrote: > On Sat, 15 Nov 2025 at 06:23, Frediano Ziglio <[email protected]> wrote: >> >> On Fri, 14 Nov 2025 at 19:18, Andrew Cooper <[email protected]> >> wrote: >>> >>> On 14/11/2025 3:40 pm, Oleksii Kurochko wrote: >>>> >>>> >>>> On 11/13/25 4:43 PM, Frediano Ziglio wrote: >>>>> From: Frediano Ziglio <[email protected]> >>>>> >>>>> For xen.gz file we strip all symbols and have an additional >>>>> xen-syms.efi file version with all symbols. >>>>> Make xen.efi more coherent stripping all symbols too. >>>>> xen-syms.efi can be used for debugging. >>>>> >>>>> Signed-off-by: Frediano Ziglio <[email protected]> >>>> Release-Acked-By: Oleksii Kurochko <[email protected]> >>>> >>>> Thanks. >>> >>> Thanks. Unfortunately CI says no. >>> >>> Ubuntu's 20.04, 18.04 and 16.04 all fail: >>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2159622869 >>> >>> From 16.04: >>> >>> 2025-11-14T18:01:51.192964Z 01O strip xen-syms.efi -o xen.efi >>> 2025-11-14T18:01:51.198151Z 01O strip:xen-syms.efi[.init]: relocation count >>> is negative: File truncated >>> 2025-11-14T18:01:51.198166Z 01O strip: xen.efi: Failed to read debug data >>> section >>> 2025-11-14T18:01:51.198169Z 01O strip:xen.efi: error copying private BFD >>> data: File truncated >>> 2025-11-14T18:01:51.198932Z 01O arch/x86/Makefile:207: recipe for target >>> 'xen.efi' failed >>> 2025-11-14T18:01:51.198937Z 01O make[3]: *** [xen.efi] Error 1 >>> 2025-11-14T18:01:51.199616Z 01O build.mk:90: recipe for target 'xen' failed >>> 2025-11-14T18:01:51.199619Z 01O make[2]: *** [xen] Error 2 >>> 2025-11-14T18:01:51.200402Z 01O Makefile:600: recipe for target 'xen' failed >>> 2025-11-14T18:01:51.200409Z 01O make[1]: *** [xen] Error 2 >>> >>> >>> I find it hard to believe that the relocation count is really negative, >>> and given that newer binuitls works, I expect this is a binutils bug. >>> >> >> Unless the message is just misleading I find it hard to have a >> negative number of items in a container. >> >>> Nevertheless, we need some workaround. Given that the previous >>> behaviour was not to strip, I think we can reuse that for broken toolchains? >>> >> >> Something like that ? >> >> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile >> index a154ffe6b2..c465eb12e2 100644 >> --- a/xen/arch/x86/Makefile >> +++ b/xen/arch/x86/Makefile >> @@ -236,7 +236,9 @@ ifeq ($(CONFIG_DEBUG_INFO),y) >> $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) \ >> -O elf64-x86-64 $(TARGET)-syms.efi [email protected] >> endif >> - $(STRIP) $(TARGET)-syms.efi -o $@ >> + $(STRIP) $(TARGET)-syms.efi -o $@ || { \ >> + LANG=C strip $(TARGET)-syms.efi -o $@ 2>&1 | grep -q \ >> + "relocation count is negative" && mv -f $(TARGET)-syms.efi >> $@; } >> ifneq ($(CONFIG_DEBUG_INFO),y) >> rm -f $(TARGET)-syms.efi >> endif >> >> It will fall back to not stripping in case that bug is detected. I >> don't know how to test it. >> (the LANG=C is to always force the English message). >> > > It looks like this change works better and CI is happy. > It duplicates the linking with -s option if the strip fails. > Yes, it's a hack and almost duplicates the one command above. > What about it?
As alluded to elsewhere - can't we detect the situation and avoid linking with debug info included in that case, like we already do for other reasons? Linking xen.efi is quite a bit slower than linking xen-syms, so the extra linking pass would better be avoided imo. Jan > --- a/xen/arch/x86/Makefile > +++ b/xen/arch/x86/Makefile > @@ -236,7 +236,10 @@ ifeq ($(CONFIG_DEBUG_INFO),y) > $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) \ > -O elf64-x86-64 $(TARGET)-syms.efi [email protected] > endif > - $(STRIP) $(TARGET)-syms.efi -o $@ > + $(STRIP) $(TARGET)-syms.efi -o $@ || \ > + $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< \ > + $(dot-target).1r.o $(dot-target).1s.o $(orphan-handling-y) \ > + $(note_file_option) -s -o $@ > ifneq ($(CONFIG_DEBUG_INFO),y) > rm -f $(TARGET)-syms.efi > endif > > Frediano
