[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251122000101.GA1996391@ax162>
Date: Fri, 21 Nov 2025 17:01:01 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Tiezhu Yang <yangtiezhu@...ngson.cn>, Ard Biesheuvel <ardb@...nel.org>,
Huacai Chen <chenhuacai@...nel.org>, linux-kbuild@...r.kernel.org,
linux-efi@...r.kernel.org, loongarch@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] kbuild: Add KBUILD_VMLINUX_LIBS_PRELINK
On Fri, Nov 21, 2025 at 10:42:47AM -0800, Josh Poimboeuf wrote:
> On Fri, Nov 21, 2025 at 12:01:40AM -0700, Nathan Chancellor wrote:
> > > @@ -1199,6 +1199,7 @@ KBUILD_VMLINUX_OBJS := built-in.a $(patsubst %/, %/lib.a, $(filter %/, $(libs-y)
> > > KBUILD_VMLINUX_LIBS := $(filter-out %/, $(libs-y))
> > >
> > > export KBUILD_VMLINUX_LIBS
> > > +export KBUILD_VMLINUX_LIBS_PRELINK
> >
> > This variable name is a little confusing to me since they do get added
> > to vmlinux during linking, not before. I am not sure of a better one
> > though, maybe KBUILD_VMLINUX_LIBS_FINAL?
>
> I think that name was my idea. Not sure what I was thinking, I guess
> "prelink" was somehow meant to imply after the vmlinux.o whole-archive
> link but before the "final" link.
Yeah I could see where you were going with that but glad we agree final
is better heh.
> "final" is indeed better.
>
> > It may also make sense to
> > introduce similar syntax to the existing libs-y syntax, maybe
> >
> > final-libs-y
> >
> > or something like that?
>
> Yeah, I suppose that would mirror how KBUILD_VMLINUX_LIBS is wired up.
On second thought, it might be less complicated to keep it this way...
> > Also, since these objects are no longer in KBUILD_VMLINUX_LIBS, does
> > this new variable need to be added to any of the other places in the
> > build system that use KBUILD_VMLINUX_LIBS for things such as build
> > dependencies?
>
> Not sure about that one. drivers/firmware/efi/libstub/lib.a is getting
> built regardless so there must already be an implicit dependency?
I think the explicit dependency currently comes from
vmlinux_o: vmlinux.a $(KBUILD_VMLINUX_LIBS)
in Makefile. I think something like
diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux
index cd788cac9d91..38b5f0ba9a4b 100644
--- a/scripts/Makefile.vmlinux
+++ b/scripts/Makefile.vmlinux
@@ -68,7 +68,7 @@ cmd_link_vmlinux = \
$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
targets += vmlinux.unstripped .vmlinux.export.o
-vmlinux.unstripped: scripts/link-vmlinux.sh vmlinux.o .vmlinux.export.o $(KBUILD_LDS) FORCE
+vmlinux.unstripped: scripts/link-vmlinux.sh vmlinux.o .vmlinux.export.o $(KBUILD_LDS) $(KBUILD_VMLINUX_LIBS_FINAL) FORCE
+$(call if_changed_dep,link_vmlinux)
ifdef CONFIG_DEBUG_INFO_BTF
vmlinux.unstripped: $(RESOLVE_BTFIDS)
is needed to ensure that an updated drivers/firmware/efi/libstub/lib.a
results in vmlinux getting regenerated (at least according to my
testing).
Cheers,
Nathan
Powered by blists - more mailing lists