On 10.11.2025 16:36, Frediano Ziglio wrote: > On Mon, 10 Nov 2025 at 13:40, Jan Beulich <[email protected]> wrote: >> On 10.11.2025 13:58, Frediano Ziglio wrote: >>> --- a/xen/arch/x86/Makefile >>> +++ b/xen/arch/x86/Makefile >>> @@ -228,17 +228,21 @@ 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 $(TARGET)-syms.efi >>> + $(NM) -pa --format=sysv $(TARGET)-syms.efi \ >>> | $(objtree)/tools/symbols --all-symbols --xensyms --sysv >>> --sort \ >>> > [email protected] >> >> This part if fine with me now. >> >>> -ifeq ($(CONFIG_DEBUG_INFO),y) >>> - $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O >>> elf64-x86-64 $@ [email protected] >>> +ifeq ($(CONFIG_DEBUG_INFO)_$(filter --strip-debug,$(EFI_LDFLAGS)),y_) >> >> This extra change looks correct to me, yet I wonder if doing it this way >> isn't >> fragile. If EFI_LDFLAGS wasn't set globally, but only for xen.efi, aiui this >> wouldn't work anymore. > > Maybe, but it's not a regression of this patch, the same test was > present before, just using another syntax
How is it not a (latent) regression? It is my understanding that the ifeq() is processed when the Makefile is parsed, whereas the original $(if ...) was processed as the rule is executed. >>> + $(OBJCOPY) -O elf64-x86-64 $(TARGET)-syms.efi [email protected] >>> + $(STRIP) $(TARGET)-syms.efi -o [email protected] >>> +else >>> + mv -f $(TARGET)-syms.efi -o [email protected] >> >> This, while I think I understand why you do it, looks somewhat odd. Plus the >> reason you do it is, like ... > > Can you explain why "it looks somewhat odd" ? You're moving a properly named file to a temporary one. (Just to later move it again.) Jan
