[PATCH] kbuild: keep .modinfo when vmlinux is linked with --gc-sections

[PATCH] kbuild: keep .modinfo when vmlinux is linked with --gc-sections

[Sasha Levin]

Builds with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y, such as arm
allmodconfig, now fail while extracting modules.builtin.modinfo:

  arm-linux-gnueabihf-objcopy: vmlinux.unstripped: can't dump section
  '.modinfo' - it does not exist: file format not recognized
  /bin/sh: 1: cannot open modules.builtin.modinfo: No such file

or, with LLVM:

  llvm-objcopy: error: 'vmlinux.unstripped': section '.modinfo' not
  found

Nothing references the MODULE_INFO() strings, so --gc-sections
discards every .modinfo input section and vmlinux.unstripped ends up
with no .modinfo data. This is not new: ever since
modules.builtin.modinfo started being extracted from
vmlinux.unstripped, these builds have silently produced an empty
file, losing the modinfo of every built-in module. An arm
multi_v7_defconfig build with LD_DEAD_CODE_DATA_ELIMINATION on current
mainline yields a 0 byte modules.builtin.modinfo. The switch to
--dump-section only turned that into a build error.

Wrap the input section in KEEP() so that the linker retains it. The
output section is still (INFO), so nothing is allocated for it. With
the same arm config, modules.builtin.modinfo now has 14119 entries,
and on x86_64 defconfig, where nothing is garbage collected, it is
byte-identical before and after this change.

Found by KernelCI builds of the linus-next tree.

Fixes: 39cfd5b12160 ("kbuild: extract modules.builtin.modinfo from vmlinux.unstripped")
Fixes: 5fe4dd596641 ("kbuild: do not allocate .modinfo in vmlinux")
Assisted-by: LLM
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 include/asm-generic/vmlinux.lds.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index a6730d34e8c67..7a3e9f00d6283 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -855,7 +855,7 @@
 		KLP_SYMID
 
 #define MODINFO								\
-		.modinfo (INFO) : { *(.modinfo) }
+		.modinfo (INFO) : { KEEP(*(.modinfo)) }
 
 #ifdef CONFIG_GENERIC_BUG
 #define BUG_TABLE							\
-- 
2.53.0

Re: [PATCH] kbuild: keep .modinfo when vmlinux is linked with --gc-sections

[Lorenzo Stoakes (ARM)]

On Sun, Sep 27, 2026 at 12:12:27PM -0400, Sasha Levin wrote:
> Builds with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y, such as arm
> allmodconfig, now fail while extracting modules.builtin.modinfo:
>
>   arm-linux-gnueabihf-objcopy: vmlinux.unstripped: can't dump section
>   '.modinfo' - it does not exist: file format not recognized
>   /bin/sh: 1: cannot open modules.builtin.modinfo: No such file
>
> or, with LLVM:
>
>   llvm-objcopy: error: 'vmlinux.unstripped': section '.modinfo' not
>   found
>
> Nothing references the MODULE_INFO() strings, so --gc-sections
> discards every .modinfo input section and vmlinux.unstripped ends up
> with no .modinfo data. This is not new: ever since
> modules.builtin.modinfo started being extracted from
> vmlinux.unstripped, these builds have silently produced an empty
> file, losing the modinfo of every built-in module. An arm
> multi_v7_defconfig build with LD_DEAD_CODE_DATA_ELIMINATION on current
> mainline yields a 0 byte modules.builtin.modinfo. The switch to
> --dump-section only turned that into a build error.

Yikes, so an existing bug but now exposed by my series.

>
> Wrap the input section in KEEP() so that the linker retains it. The
> output section is still (INFO), so nothing is allocated for it. With
> the same arm config, modules.builtin.modinfo now has 14119 entries,
> and on x86_64 defconfig, where nothing is garbage collected, it is
> byte-identical before and after this change.

Sounds reasonable.

>
> Found by KernelCI builds of the linus-next tree.
>
> Fixes: 39cfd5b12160 ("kbuild: extract modules.builtin.modinfo from vmlinux.unstripped")
> Fixes: 5fe4dd596641 ("kbuild: do not allocate .modinfo in vmlinux")
> Assisted-by: LLM
> Signed-off-by: Sasha Levin <sashal@kernel.org>

Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>

Nathan - do you want me to fold this into the 1st patch of my series on respin
or fine to treat separately?

> ---
>  include/asm-generic/vmlinux.lds.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index a6730d34e8c67..7a3e9f00d6283 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -855,7 +855,7 @@
>  		KLP_SYMID
>
>  #define MODINFO								\
> -		.modinfo (INFO) : { *(.modinfo) }
> +		.modinfo (INFO) : { KEEP(*(.modinfo)) }
>
>  #ifdef CONFIG_GENERIC_BUG
>  #define BUG_TABLE							\
> --
> 2.53.0
>

--
Cheers, Lorenzo

Re: [PATCH] kbuild: keep .modinfo when vmlinux is linked with --gc-sections

[Nathan Chancellor]

On Mon, Sep 28, 2026 at 12:15:46PM +0100, Lorenzo Stoakes (ARM) wrote:
> Nathan - do you want me to fold this into the 1st patch of my series on respin
> or fine to treat separately?

Let's keep it separate since it is an existing issue and might want
to be backported in its own right.

I applied a subset of your series to kbuild-next-speedups to begin
exposing the "ready to go" (IMO at least) bits to -next (good thing
since it found this). You should be able to rebase on that for
subsequent versions, although maybe we still want to include those
changes for
others to continue to review but *shrug*. If there are follow up review
comments, just send delta patches and I will decide if I want to keep
them separate or squash them.

-- 
Cheers,
Nathan

Re: [PATCH] kbuild: keep .modinfo when vmlinux is linked with --gc-sections

[Lorenzo Stoakes (ARM)]

On Mon, Sep 28, 2026 at 01:56:28PM +0200, Nathan Chancellor wrote:
> On Mon, Sep 28, 2026 at 12:15:46PM +0100, Lorenzo Stoakes (ARM) wrote:
> > Nathan - do you want me to fold this into the 1st patch of my series on respin
> > or fine to treat separately?
>
> Let's keep it separate since it is an existing issue and might want
> to be backported in its own right.
>
> I applied a subset of your series to kbuild-next-speedups to begin
> exposing the "ready to go" (IMO at least) bits to -next (good thing
> since it found this). You should be able to rebase on that for
> subsequent versions, although maybe we still want to include those
> changes for
> others to continue to review but *shrug*. If there are follow up review
> comments, just send delta patches and I will decide if I want to keep
> them separate or squash them.

Ack, will rebase on that and send deltas from here on out on those.

Easiest to keep things straight on my side would be to stop sending those
patches, I can list them in the cover letter with links to the originals
for any further review?

As for what remains, is there anything else I need to do?

I think timing this week is less than ideal with LPC next week so people
have less time to go through it but it does feel like things are
stabilising (despite the large changelog for v4 ;)

Thanks for all your help with this! Is much appreciated.

>
> --
> Cheers,
> Nathan

--
Cheers, Lorenzo