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

[Frediano Ziglio <freddy77@gmail.com>]

On Fri, 7 Nov 2025 at 07:08, Jan Beulich <jbeulich@suse.com> wrote:
>
> On 06.11.2025 17:37, Frediano Ziglio wrote:
> > On Thu, 6 Nov 2025 at 10:32, Jan Beulich <jbeulich@suse.com> wrote:
> >> On 05.11.2025 16:38, Frediano Ziglio wrote:
> >>> --- a/xen/Kconfig.debug
> >>> +++ b/xen/Kconfig.debug
> >>> @@ -147,12 +147,7 @@ config DEBUG_INFO
> >>>         Say Y here if you want to build Xen with debug information. This
> >>>         information is needed e.g. for doing crash dump analysis of the
> >>>         hypervisor via the "crash" tool.
> >>> -       Saying Y will increase the size of the xen-syms and xen.efi
> >>> -       binaries. In case the space on the EFI boot partition is rather
> >>> -       limited, you may want to install a stripped variant of xen.efi in
> >>> -       the EFI boot partition (look for "INSTALL_EFI_STRIP" in
> >>> -       docs/misc/efi.pandoc for more information - when not using
> >>> -       "make install-xen" for installing xen.efi, stripping needs to be
> >>> -       done outside the Xen build environment).
> >>> +       Saying Y will increase the size of the xen-syms and xen.efi.elf
> >>> +       binaries.
> >>
> >> Why xen.efi.elf and not xen-syms.efi?
> >>
> >
> > I forgot to update this part.
> > Now that I see the comment, was the suggestion about having an
> > additional xen-syms.efi file or having xen-syms.efi instead of
> > xen.efi.elf ?
>
> The former. We want to have the binary available that the linker produced
> directly. Anything else are extra's for what people think they may need.
>

Done in v4.

> >>> --- a/xen/arch/x86/Makefile
> >>> +++ b/xen/arch/x86/Makefile
> >>> @@ -228,14 +228,17 @@ endif
> >>>       $(MAKE) $(build)=$(@D) .$(@F).1r.o .$(@F).1s.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) -o $@
> >>> -     $(NM) -pa --format=sysv $@ \
> >>> +           $(note_file_option) -o $@.tmp
> >>> +     $(NM) -pa --format=sysv $@.tmp \
> >>>               | $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
> >>>               > $@.map
> >>>  ifeq ($(CONFIG_DEBUG_INFO),y)
> >>> -     $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O elf64-x86-64 $@ $@.elf
> >>> +     $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))cp -f \
> >>> +        $@.tmp $(TARGET)-syms.efi
> >>> +     $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(STRIP) $@.tmp
> >>>  endif
> >>>       rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
> >>> +     mv -f $@.tmp $@
> >>>  ifeq ($(CONFIG_XEN_IBT),y)
> >>>       $(SHELL) $(srctree)/tools/check-endbr.sh $@
> >>>  endif
> >>
> >> I see $@.tmp here, but no sign of xen-syms. Did you submit a stake patch? Am
> >> I missing something?
> >>
> >
> > I don't know what a "stake patch" is.
>
> Sorry, typo - "stale" was meant.
>
> > xen-syms.efi (that is $(TARGET)-syms.efi in the Makefile) is not a
> > target of this rule so if the rule fails it will be generated again.
>
> How does this matter in this context? The description talks of a xen-syms.efi
> being generated, yet I'm simply unable to spot where that would be happening.
>

It was "generated" with a "cp" command, now I use "mv" + "strip -o"
(in v4) to make it more clear.

> >> I also think the mv should sit ahead of the cleaning-up rm.
> >
> > Are you sure?
> > Usually you want it as the last command so any failure won't create
> > the target. For instance here if check-endbr.sh is failing the target
> > is still created and next make command will succeed.
>
> Except that the rm is tidying up rather than creating anything.
>

Updated this moving endbr check before the "mv" and the cleanup after.

> Jan

Frediano