public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alexey Gladkov <legion@kernel.org>
To: Daniel Golle <daniel@makrotopia.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>,
	John Crispin <john@phrozen.org>, Nicolas Schier <nsc@kernel.org>,
	Nathan Chancellor <nathan@kernel.org>,
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [BUG] kbuild: modules.builtin is empty on architectures without CONFIG_ARCH_VMLINUX_NEEDS_RELOCS
Date: Wed, 15 Oct 2025 19:05:43 +0200	[thread overview]
Message-ID: <aO_UZ6M_J9YMVuMI@example.org> (raw)
In-Reply-To: <aO-kDdBybaHSn62G@makrotopia.org>

On Wed, Oct 15, 2025 at 02:39:25PM +0100, Daniel Golle wrote:
> 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

Hm. At least on arm64, it doesn't reproduce with these parameters.

$ grep -w -e CONFIG_MODULES -e CONFIG_ARCH_VMLINUX_NEEDS_RELOCS .config
CONFIG_MODULES=y

$ ARCH=arm64 CROSS_COMPILE=aarch64-unknown-linux-gnu- make
/tmp/linux/Makefile:1133: CONFIG_ARCH_VMLINUX_NEEDS_RELOCS=""
  CALL    scripts/checksyscalls.sh
  OBJCOPY modules.builtin.modinfo
  GEN     modules.builtin

$ ls -lh modules.builtin modules.builtin.modinfo 
-rw-r--r-- 1 legion legion 1.1K Oct 15 18:59 modules.builtin
-rw-r--r-- 1 legion legion  14K Oct 15 18:59 modules.builtin.modinfo

I'll try to reproduce it on mips.

> 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
> 

-- 
Rgrds, legion


  reply	other threads:[~2025-10-15 17:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-15 13:39 [BUG] kbuild: modules.builtin is empty on architectures without CONFIG_ARCH_VMLINUX_NEEDS_RELOCS Daniel Golle
2025-10-15 17:05 ` Alexey Gladkov [this message]
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_UZ6M_J9YMVuMI@example.org \
    --to=legion@kernel.org \
    --cc=daniel@makrotopia.org \
    --cc=john@phrozen.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