On 06.11.2025 17:37, Frediano Ziglio wrote: > On Thu, 6 Nov 2025 at 10:32, Jan Beulich <[email protected]> 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 [email protected] >>> + $(NM) -pa --format=sysv [email protected] \ >>> | $(objtree)/tools/symbols --all-symbols --xensyms --sysv >>> --sort \ >>> > [email protected] >>> ifeq ($(CONFIG_DEBUG_INFO),y) >>> - $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O >>> elf64-x86-64 $@ [email protected] >>> + $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))cp -f \ >>> + [email protected] $(TARGET)-syms.efi >>> + $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(STRIP) [email protected] >>> endif >>> rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]* >>> + mv -f [email protected] $@ >>> ifeq ($(CONFIG_XEN_IBT),y) >>> $(SHELL) $(srctree)/tools/check-endbr.sh $@ >>> endif >> >> I see [email protected] 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
