From: Daniel Golle <daniel@makrotopia.org>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: John Crispin <john@phrozen.org>,
Alexey Gladkov <legion@kernel.org>,
Nicolas Schier <nsc@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [BUG] kbuild: modules.builtin is empty on architectures without CONFIG_ARCH_VMLINUX_NEEDS_RELOCS
Date: Wed, 15 Oct 2025 14:39:25 +0100 [thread overview]
Message-ID: <aO-kDdBybaHSn62G@makrotopia.org> (raw)
Hi,
While build todays net-next tree on a Lantiq-based board I use for
testing I run into a weird problem which gave me some headaches. It
turns there is a regression introduced in commit 39cfd5b12160 ("kbuild:
extract modules.builtin.modinfo from vmlinux.unstripped") which causes
both modules.builtin and modules.builtin.modinfo to be empty files on
certain architectures.
AFFECTED SCOPE:
===============
This bug affects all architectures where:
1. CONFIG_ARCH_VMLINUX_NEEDS_RELOCS is NOT set, AND
2. The architecture uses the standard ELF_DETAILS macro in its linker
script (which places .modinfo at address 0 as a non-allocatable
section)
This includes at least MIPS (32-bit and 64-bit) and likely several other
architectures. The issue does NOT affect architectures with
CONFIG_ARCH_VMLINUX_NEEDS_RELOCS=y (e.g., x86 with certain
configurations, parisc, s390).
OBSERVED BEHAVIOR:
==================
After a successful kernel build with the affected configuration:
- modules.builtin: 0 bytes (empty)
- modules.builtin.modinfo: 0 bytes (empty)
- vmlinux.o: contains .modinfo section (verified with readelf)
- vmlinux.unstripped: .modinfo section is MISSING (verified with
readelf)
This breaks any build tooling that depends on modules.builtin to
determine which drivers are built into the kernel image, such as
OpenWrt's build system.
ROOT CAUSE ANALYSIS:
====================
Commit 39cfd5b12160 moved the extraction of modules.builtin.modinfo from
vmlinux.o to vmlinux.unstripped. The commit message states:
"Currently, we assume all the data for modules.builtin.modinfo are
available in vmlinux.o."
However, this change makes a NEW assumption that was not explicitly
documented or validated: it assumes that the .modinfo section will be
present in vmlinux.unstripped.
The problem occurs during the linking phase
(vmlinux.o -> vmlinux.unstripped):
1. The .modinfo section is defined in include/asm-generic/vmlinux.lds.h
as part of ELF_DETAILS:
.modinfo : { *(.modinfo) }
This places it at address 0 (non-allocatable, similar to .comment,
.symtab, etc.)
2. When CONFIG_ARCH_VMLINUX_NEEDS_RELOCS is NOT set, the Makefile does NOT
add "--discard-none" to LDFLAGS_vmlinux (see Makefile line 1133-1135):
ifneq ($(CONFIG_ARCH_VMLINUX_NEEDS_RELOCS),)
LDFLAGS_vmlinux += --emit-relocs --discard-none
endif
3. Without "--discard-none", the GNU linker (ld) applies its default
behavior: it discards unreferenced sections with address 0 that are
not marked as allocatable.
4. The .modinfo section is unreferenced from the linker's perspective
(no code/data references it directly), so it gets discarded.
5. In scripts/Makefile.vmlinux line 107, objcopy attempts to extract
.modinfo from vmlinux.unstripped:
modules.builtin.modinfo: vmlinux.unstripped FORCE
$(call if_changed,objcopy)
But since .modinfo was discarded, objcopy produces an empty file.
6. Subsequently, modules.builtin (which depends on
modules.builtin.modinfo) is also empty.
WHY THE PREVIOUS CODE WORKED:
==============================
Before commit 39cfd5b12160, modules.builtin.modinfo was extracted from
vmlinux.o (in scripts/Makefile.vmlinux_o). The .modinfo section was
reliably present in vmlinux.o because:
- vmlinux.o is the direct output of object file linking
- No section stripping occurs at this stage
- The section contains actual data (module metadata from __MODULE_INFO)
REPRODUCTION:
=============
1. Configure a kernel for MIPS (or any other architecture without
CONFIG_ARCH_VMLINUX_NEEDS_RELOCS)
2. Ensure CONFIG_MODULES=y is set
3. Build the kernel: make
4. Observe: ls -lh modules.builtin modules.builtin.modinfo
Both files will be 0 bytes
VERIFICATION:
=============
You can verify the .modinfo section presence:
$ readelf -S vmlinux.o | grep modinfo
[51265] .modinfo PROGBITS 00000000 919448 00803e 00 A 0 0 1
$ readelf -S vmlinux.unstripped | grep modinfo
(no output - section is missing)
IMPACT:
=======
This is a build system regression that breaks kernel builds for downstream
projects (like OpenWrt) that rely on modules.builtin. Since the file is
silently empty rather than causing a build failure, it can lead to incorrect
packaging and deployment decisions.
The regression is present in v6.18-rc1 and later kernels.
I'm happy to test any proposed patches. Please let me know if you need
additional information or testing.
Best regards,
Daniel Golle
next reply other threads:[~2025-10-15 13:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-15 13:39 Daniel Golle [this message]
2025-10-15 17:05 ` [BUG] kbuild: modules.builtin is empty on architectures without CONFIG_ARCH_VMLINUX_NEEDS_RELOCS Alexey Gladkov
2025-10-15 17:29 ` 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=aO-kDdBybaHSn62G@makrotopia.org \
--to=daniel@makrotopia.org \
--cc=john@phrozen.org \
--cc=legion@kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=nathan@kernel.org \
--cc=nsc@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox