Re: [PATCH v8] xen: Strip xen.efi by default

[Frediano Ziglio <freddy77@xxxxxxxxx>]

On Thu, 20 Nov 2025 at 14:05, Marek Marczykowski-Górecki
<marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Thu, Nov 20, 2025 at 01:59:24PM +0000, Frediano Ziglio wrote:
> > On Sat, 15 Nov 2025 at 06:23, Frediano Ziglio <freddy77@xxxxxxxxx> wrote:
> > >
> > > On Fri, 14 Nov 2025 at 19:18, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 
> > > wrote:
> > > >
> > > > On 14/11/2025 3:40 pm, Oleksii Kurochko wrote:
> > > > >
> > > > >
> > > > > On 11/13/25 4:43 PM, Frediano Ziglio wrote:
> > > > >> From: Frediano Ziglio <frediano.ziglio@xxxxxxxxx>
> > > > >>
> > > > >> 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 <frediano.ziglio@xxxxxxxxx>
> > > > > Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
> > > > >
> > > > > 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 $@.elf
> > >  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?
>
> Is it guaranteed to match xen-syms.efi?
>
> There is an alternative option: based on observation that Ubuntu 16.04
> runs out of support in April 2026 - which is before Xen 4.22 release,
> maybe we can drop that test from CI already?
>

That would work too.

Looking a bit more at the logs from
https://gitlab.com/xen-project/people/fziglio/xen/-/jobs/12158955130/viewer
there's something that worries me about.
I added "ls -l" and "objdump -x" of the output file and objdump is
complaining about relocations more or less the same strip was
complaining about:

    RELOCATION RECORDS FOR [.init]:
    objdump: failed to read relocs in: xen-syms.efi
    objdump: error message was: File truncated

not counting some weird relocations:

    reloc 2060 offset    0 [a4b8a4b0] UNKNOWN

    reloc 2294 offset    0 [a4b8a4b0] HIGHADJ (  80)

    reloc 2348 offset    0 [a4b8a4b0] SECTION

    reloc 2372 offset    0 [a4b8a4b0] RESERVED1

    reloc 2730 offset    0 [a4b8a4b0] MIPS_JMPADDR

Maybe the CI now is happy but there's not much point if the produced
files are not working.

> > diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> > index a154ffe6b2..5f5162841e 100644
> > --- 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 $@.elf
> >  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
> >