From: Nathan Chancellor <nathan@kernel.org>
To: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Tiezhu Yang <yangtiezhu@loongson.cn>,
Ard Biesheuvel <ardb@kernel.org>,
Huacai Chen <chenhuacai@kernel.org>,
linux-kbuild@vger.kernel.org, linux-efi@vger.kernel.org,
loongarch@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] kbuild: Add KBUILD_VMLINUX_LIBS_PRELINK
Date: Fri, 21 Nov 2025 17:01:01 -0700 [thread overview]
Message-ID: <20251122000101.GA1996391@ax162> (raw)
In-Reply-To: <hka6ukulmkmxp7mrcmxmllco2sqof2elextc7ggcikazfzmwni@a4pnogedcr7r>
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
WARNING: multiple messages have this Message-ID (diff)
From: Nathan Chancellor <nathan@kernel.org>
To: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Tiezhu Yang <yangtiezhu@loongson.cn>,
Ard Biesheuvel <ardb@kernel.org>,
Huacai Chen <chenhuacai@kernel.org>,
linux-kbuild@vger.kernel.org, linux-efi@vger.kernel.org,
loongarch@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] kbuild: Add KBUILD_VMLINUX_LIBS_PRELINK
Date: Fri, 21 Nov 2025 17:01:01 -0700 [thread overview]
Message-ID: <20251122000101.GA1996391@ax162> (raw)
In-Reply-To: <hka6ukulmkmxp7mrcmxmllco2sqof2elextc7ggcikazfzmwni@a4pnogedcr7r>
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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2025-11-22 0:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-19 4:27 [PATCH v1] kbuild: Add KBUILD_VMLINUX_LIBS_PRELINK Tiezhu Yang
2025-11-19 4:27 ` Tiezhu Yang
2025-11-21 7:01 ` Nathan Chancellor
2025-11-21 7:01 ` Nathan Chancellor
2025-11-21 18:42 ` Josh Poimboeuf
2025-11-21 18:42 ` Josh Poimboeuf
2025-11-22 0:01 ` Nathan Chancellor [this message]
2025-11-22 0:01 ` Nathan Chancellor
2025-11-22 1:35 ` Nathan Chancellor
2025-11-22 1:35 ` Nathan Chancellor
2025-11-22 11:26 ` Tiezhu Yang
2025-11-22 11:26 ` Tiezhu Yang
2025-11-23 21:15 ` Nathan Chancellor
2025-11-23 21:15 ` Nathan Chancellor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251122000101.GA1996391@ax162 \
--to=nathan@kernel.org \
--cc=ardb@kernel.org \
--cc=chenhuacai@kernel.org \
--cc=jpoimboe@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=loongarch@lists.linux.dev \
--cc=yangtiezhu@loongson.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.