On 19/11/2025 3:06 pm, Marek Marczykowski-Górecki wrote: > On Sat, Nov 15, 2025 at 06:23:08AM +0000, Frediano Ziglio 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 > On Ubuntu 20.04 it fails different way: > > strip: xen.efi: Data Directory size (1c) exceeds space left in section > (18) > strip: xen.efi: error copying private BFD data: file in wrong format > > Looks similar to: > https://lore.kernel.org/all/3TMd7J2u5gCA8ouIG_Xfcw7s5JKMG06XsDIesEB3Fi9htUJ43Lfl057wXohlpCHcszqoCmicpIlneEDO26ZqT8QfC2Y39VxBuqD3nS1j5Q4=@trmm.net/ > > Qubes has this patch: > https://github.com/QubesOS/qubes-vmm-xen/blob/main/0608-Fix-buildid-alignment.patch > > diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S > index 9a1dfe1b340a..26a23a7b0651 100644 > --- a/xen/arch/x86/xen.lds.S > +++ b/xen/arch/x86/xen.lds.S > @@ -171,6 +171,7 @@ SECTIONS > __note_gnu_build_id_end = .; > } PHDR(note) PHDR(text) > #elif defined(BUILD_ID_EFI) > + . = ALIGN(32); > DECL_SECTION(.buildid) { > __note_gnu_build_id_start = .; > *(.buildid) > > Lets see if that helps: > https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/2167783980
That seems to have fixed 20.04 and 18.04. The extra line wants a comment at least identifying roughly which binutils it's a workaround for, so we can drop it eventually. And, as it's already in a downstream, it should be upstreamed and backported. > > And few lines earlier there is also: > > ld: xen-syms.efi: warning: section .init: alignment 2**15 not > representable This can't be helped. It's not an error, but you also cant get LD to shut up about it. > >> 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). > If going this way, use LC_ALL=C (otherwise LC_ALL=something present in > the env would override your LANG=C). But given there are different > messages, this may not be the best option. > > And TBH, I don't like silent behavior change based on (unknown) version > of binutils. Lets see if the alignment adjustment helps. While it > shouldn't be necessary on newer binutils (thanks to Jan's fix there - > see thread linked above), IMO it isn't too bad to add it, to keep older > versions happy. And it can be dropped, once we raise toolchain base > version next time. Given it's now only 16.04 broken, how about simply excluding xen.efi with these broken toolchains? ~Andrew
