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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.11.2025 17:37, Frediano Ziglio wrote:
> On Thu, 6 Nov 2025 at 10:32, Jan Beulich <jbeulich@xxxxxxxx> 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.

>>> --- 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.

>> 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.

Jan