On Mon, 22 May 2023 at 03:15, Pedro Falcato <pedro.falcato@xxxxxxxxx> wrote: > > On Mon, May 22, 2023 at 1:43 AM Bagas Sanjaya <bagasdotme@xxxxxxxxx> wrote: > > > > Hi, > > > > I notice a simple build-time regression on Bugzilla [1]. Quoting from it: > > > > > This is a very simple to see regression. > > > > > > On arm64 hardware, take any one of the -6.4-rcY tarballs created by Linus. Extract the contents of the tarball and cd to the linux-6.4-rcY directory. Issue a "make clean" or a "make mrproper" or a "make distclean" command. Look at the output (there should not be any). In every case, the output is -- > > > > > > nm: 'vmlinux': No such file > > > ... > > > # first bad commit: [45dd403da851124412d32e3193c21de4a51d29da] efi/zboot: arm64: Inject kernel code size symbol into the zboot payload > > > > > > Reverting the commit 45dd403da851124412d32e3193c21de4a51d29da resolves the problem. > > > > The regression looks like arm-specific, but the first bad commit > > IMO isn't related to kbuild system. > > > > Anyway, I'm adding it to regzbot: > > > > #regzbot introduced: 45dd403da85112 https://bugzilla.kernel.org/show_bug.cgi?id=217468 > > #regzbot title: nm vmlinux ENOENT when "make mrproper" on arm64 > How on earth is this a regression? It is not even a build error, only a warning, with no adverse impact whatsoever on the resulting binaries. Could we stop being so trigger happy when calling things regressions, please? > I was able to track down the issue. > In line 47, arch/arm64/boot/Makefile, a variable (that gets expanded > on use, hence = and not :=) gets defined, that requires vmlinux to > exist (see the $(shell) invocation). > drivers/firmware/efi/libstub/Makefile.zboot then defines a variable > with :=, which expands on site and not when it actually needs to be > used. This expands EFI_ZBOOT_OBJCOPY_FLAGS without vmlinux existing, > which ENOENTs. > > The below patch should fix it. I'm not submitting an actual patch > because I simply don't know if there are any possible side effects > here (although it frankly seems unlikely). > > diff --git a/drivers/firmware/efi/libstub/Makefile.zboot > b/drivers/firmware/efi/libstub/Makefile.zboot > index 89ef820f3b3..3fb39dea114 100644 > --- a/drivers/firmware/efi/libstub/Makefile.zboot > +++ b/drivers/firmware/efi/libstub/Makefile.zboot > @@ -32,7 +32,7 @@ zboot-size-len-$(CONFIG_KERNEL_GZIP) := 0 > $(obj)/vmlinuz: $(obj)/vmlinux.bin FORCE > $(call if_changed,$(zboot-method-y)) > > -OBJCOPYFLAGS_vmlinuz.o := -I binary -O $(EFI_ZBOOT_BFD_TARGET) > $(EFI_ZBOOT_OBJCOPY_FLAGS) \ > +OBJCOPYFLAGS_vmlinuz.o = -I binary -O $(EFI_ZBOOT_BFD_TARGET) > $(EFI_ZBOOT_OBJCOPY_FLAGS) \ > --rename-section > .data=.gzdata,load,alloc,readonly,contents > $(obj)/vmlinuz.o: $(obj)/vmlinuz FORCE > $(call if_changed,objcopy) > Thanks for the fix. So the reason I used = and not := in the first place in the assignment of EFI_ZBOOT_OBJCOPY_FLAGS was to ensure that it will not be evaluated eagerly, but obviously, forcing the eager evaluation further down defeats that. I've sent this out as a patch and queued it up as a EFI fix. Thanks!
