kbuild: keep .modinfo when vmlinux is linked with --gc-sections
PATCH 1/1 kbuild: keep .modinfo when vmlinux is linked with --gc-sections
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.
--- include/asm-generic/vmlinux.lds.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/asm-generic/vmlinux.lds.h +1 -1
@@ -855,7 +855,7 @@ KLP_SYMID#define MODINFO \ - .modinfo (INFO) : { *(.modinfo) } + .modinfo (INFO) : { KEEP(*(.modinfo)) }#ifdef CONFIG_GENERIC_BUG #define BUG_TABLE \
Signature · 1 line
2.53.0
Quoted 12 lines · 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 fileor, with LLVM:
llvm-objcopy: error: 'vmlinux.unstripped': section '.modinfo' not found
Quoted 9 lines
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 armmulti_v7_defconfigbuild withLD_DEAD_CODE_DATA_ELIMINATIONon 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.
Quoted 6 lines
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 onx86_64defconfig, where nothing is garbage collected, it is byte-identical before and after this change.
Sounds reasonable.
Quoted 7 lines
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 LLMSigned-off-by Sasha Levin <[email protected]>
Nathan - do you want me to fold this into the 1st patch of my series on respin or fine to treat separately?
Quoted 18 lines
--- include/asm-generic/vmlinux.lds.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)include/asm-generic/vmlinux.lds.h +1
-2@@ -855,7 +855,7 @@ KLP_SYMID#define MODINFO \ - .modinfo (INFO) : { *(.modinfo) } + .modinfo (INFO) : { KEEP(*(.modinfo)) }#ifdef CONFIG_GENERIC_BUG #define BUG_TABLE \ --
Quoted 2 lines
2.53.0
--
Cheers, Lorenzo
Quoted 2 lines · Lorenzo Stoakes (ARM)
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.
Signature · 2 lines
Cheers, Nathan
Quoted 7 lines · Nathan Chancellor
Quoted 2 lines · Lorenzo Stoakes (ARM)
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.
Quoted 8 lines
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.
Quoted 4 lines
--
Cheers,
Nathan
--
Cheers, Lorenzo
Quoted 5 lines · Lorenzo Stoakes (ARM)
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?
Sure, that sounds totally reasonable to me.
Quoted 5 lines
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 ;)
Yeah, I have been spread quite thin between trying to keep the current ClangBuiltLinux continuous integration setup green, developing a new one due to changing constraints elsewhere, updating my own personal testing framework to be quicker for more efficient local testing (especially for stuff like this), and my Kbuild maintainer duties, in addition to some personal time off for my wife's birthday before Plumbers.
All that to say, I am not sure how much else I will want to take for 7.4 at this point, as I would like to have the kbuild tree basically finalized by 7.3-rc7, which is the weekend right after Plumbers if my calendar is correct. I would like to study these patches to make sure I understand everything well and I don't think I will have the time to do that until after the 7.4 merge window opens.
Quoted 1 line
Thanks for all your help with this! Is much appreciated.
Absolutely, thanks for engaging and trying to make Kbuild better :)
Signature · 2 lines
Cheers, Nathan
Quoted 8 lines · Nathan Chancellor
Quoted 5 lines · Lorenzo Stoakes (ARM)
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?
Sure, that sounds totally reasonable to me.
Thanks!
Quoted 7 lines
Quoted 6 lines
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 ;)
Quoted 6 lines
Yeah, I have been spread quite thin between trying to keep the current ClangBuiltLinux continuous integration setup green, developing a new one due to changing constraints elsewhere, updating my own personal testing framework to be quicker for more efficient local testing (especially for stuff like this), and my
Kbuildmaintainer duties, in addition to some personal time off for my wife's birthday before Plumbers.
Yeah indeed, totally understood. And I hope you enjoy your time off :)
This cycle has been crazy (2x baseline for 2025 and it seems that way across many subsystems), and the LPC timing is unfortunate, so I can fully understand why people have had less time for this series.
(I also have a personal interest in clang working for the kernel also as all my builds are clang-by-default now and have been for a while!)
Quoted 7 lines
All that to say, I am not sure how much else I will want to take for 7.4 at this point, as I would like to have the kbuild tree basically finalized by 7.3-rc7, which is the weekend right after Plumbers if my calendar is correct. I would like to study these patches to make sure I understand everything well and I don't think I will have the time to do that until after the 7.4 merge window opens.
Sure, fully understood!
Stripping the stuff you have queued up from the series (+ sending deltas if needed) will make it easier to send the rest post-merge window anyway.
Quoted 4 lines
Quoted 2 lines
Thanks for all your help with this! Is much appreciated.
Absolutely, thanks for engaging and trying to make
Kbuildbetter :)
No worries :)
Quoted 4 lines
--
Cheers,
Nathan
--
Cheers, Lorenzo