Re: linux-next: new objtool warnings

[Nathan Chancellor <nathan@kernel.org>]

Hey Peter,

On Wed, Nov 05, 2025 at 11:10:10AM +0100, Peter Zijlstra wrote:
> + Nathan

Thanks for the heads up.

> On Wed, Nov 05, 2025 at 11:02:02AM +0100, Peter Zijlstra wrote:
> > Also, someone wrecked the build system.
> > 
> > vmlinux.o is no longer a valid build target, and the vmlinux target
> > seems to build a ton of module stuff :/

I tested the major stable releases (6.1, 6.6, and 6.12), long before
Nicolas and I took over Kbuild, and vmlinux.o does not work as a target
in any of them:

  $ make -skj"$(nproc)" ARCH=x86_64 mrproper
  $ make -skj"$(nproc)" ARCH=x86_64 defconfig
  $ make -skj"$(nproc)" ARCH=x86_64 vmlinux.o
  Makefile:1912: warning: overriding recipe for target 'vmlinux.o'
  Makefile:1150: warning: ignoring old recipe for target 'vmlinux.o'
  make[2]: *** No rule to make target 'vmlinux.o'.

When did this work? Is it configuration dependent? FWIW, it looks like
the 'vmlinux_o' targets does the right thing? I am not sure why it
exists instead of just vmlinux.o, Masahiro did that in commit
7a342e6c7735 ("kbuild: move modules.builtin(.modinfo) rules to
Makefile.vmlinux_o") in 6.1.

As for the second comment, if I build the vmlinux target, I see:

  AR      built-in.a
  AR      vmlinux.a
  LD      vmlinux.o
  MODPOST vmlinux.symvers
  CC      .vmlinux.export.o
  UPD     include/generated/utsversion.h
  CC      init/version-timestamp.o
  KSYMS   .tmp_vmlinux0.kallsyms.S
  AS      .tmp_vmlinux0.kallsyms.o
  LD      .tmp_vmlinux1
  NM      .tmp_vmlinux1.syms
  KSYMS   .tmp_vmlinux1.kallsyms.S
  AS      .tmp_vmlinux1.kallsyms.o
  LD      .tmp_vmlinux2
  NM      .tmp_vmlinux2.syms
  KSYMS   .tmp_vmlinux2.kallsyms.S
  AS      .tmp_vmlinux2.kallsyms.o
  LD      vmlinux.unstripped
  NM      System.map
  SORTTAB vmlinux.unstripped
  OBJCOPY vmlinux
  OBJCOPY modules.builtin.modinfo
  GEN     modules.builtin

at the end of the build with no instances of [M]. What "ton of module
stuff" are you seeing in your build? Also configuration dependent?

Cheers,
Nathan