Re: [PATCH v7 3/8] kbuild: keep .modinfo section in vmlinux.unstripped

Nicolas Schier
2025-09-16T13:35:56Z

On Tue, Sep 16, 2025 at 03:03:46PM +0200, Alexey Gladkov wrote:
> On Tue, Sep 16, 2025 at 02:42:48PM +0200, Nicolas Schier wrote:
> > > > > > Hi Alexey,
> > > > > >
> > > > > > with this patch applied, I still get a warning from objcpy as Masahiro
> > > > > > and Stephen wrote [1,2]
> > > > > >
> > > > > > SORTTAB vmlinux.unstripped
> > > > > > + sorttable vmlinux.unstripped
> > > > > > + nm -S vmlinux.unstripped
> > > > > > + ./scripts/sorttable -s .tmp_vmlinux.nm-sort vmlinux.unstripped
> > > > > > + is_enabled CONFIG_KALLSYMS
> > > > > > + grep -q ^CONFIG_KALLSYMS=y include/config/auto.conf
> > > > > > + cmp -s System.map .tmp_vmlinux2.syms
> > > > > > + echo vmlinux.unstripped: ../scripts/link-vmlinux.sh
> > > > > > # OBJCOPY vmlinux
> > > > > > objcopy --remove-section=.modinfo vmlinux.unstripped vmlinux
> > > > > > objcopy: vmlinux.unstripped: warning: empty loadable segment detected at vaddr=0xffff8000807a0000, is this intentional?
> > > > > >
> > > > > > (arm64, allnoconfig)
> > > > > >
> > > > > > Kind regards,
> > > > > > Nicolas
> > > > > >
> > > > > >
> > > > > > [1]: https://lore.kernel.org/linux-kbuild/CAK7LNAR-gD2H6Kk-rZjo0R3weTHCGTm0a=u2tRH1WWW6Sx6=RQ@mail.gmail.com/
> > > > > > [2]: https://lore.kernel.org/lkml/20250730164047.7c4a731a@canb.auug.org.au/
> > > > > >
> > > > >
> > > > > Hm. I missed that. I need to investigate how to fix this. Nothing comes
> > > > > to mind right now.
> > > >
> > > > Same here. Only thing I could find until now is
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/scripts/link-vmlinux.sh?id=90ceddcb495008ac8ba7a3dce297841efcd7d584
> > > >
> > > > where '2>/dev/null' is appended exactly to prevent this very warning.
> > > > But for me, it doesn't feel good doing that when stripping to vmlinux.
> > >
> > > Yes, that's not a very good approach. It will hide other errors that will
> > > definitely need to be seen. I think the commit you mentioned is actually
> > > incorrect. I think there should be a different solution.
> > >
> > > I think in the case of .modinfo, we can change the flag in the section
> > > since we are going to delete it anyway.
> > >
> > > diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux
> > > index dbbe3bf0cf23..9a118b31d0dc 100644
> > > --- a/scripts/Makefile.vmlinux
> > > +++ b/scripts/Makefile.vmlinux
> > > @@ -87,7 +87,8 @@ remove-section-$(CONFIG_ARCH_VMLINUX_NEEDS_RELOCS) += '.rel*'
> > > remove-symbols := -w --strip-symbol='__mod_device_table__*'
> > >
> > > quiet_cmd_strip_relocs = OBJCOPY $@
> > > - cmd_strip_relocs = $(OBJCOPY) $(addprefix --remove-section=,$(remove-section-y)) \
> > > + cmd_strip_relocs = $(OBJCOPY) $(patsubst %,--set-section-flags %=noload,$(remove-section-y)) $< && \
> > > + $(OBJCOPY) $(addprefix --remove-section=,$(remove-section-y)) \
> > > $(remove-symbols) $< $@
> > >
> > > targets += vmlinux
> >
> > Ah, great! I thought we had to fiddle around with linker scripts et al.
> > I needed to use an intermediate file:
> >
> > diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux
> > index e2ceeb9e168d..516d51ca634b 100644
> > --- a/scripts/Makefile.vmlinux
> > +++ b/scripts/Makefile.vmlinux
> > @@ -90,6 +90,9 @@ remove-section-y := .modinfo
> > remove-section-$(CONFIG_ARCH_VMLINUX_NEEDS_RELOCS) += '.rel*'
> >
> > quiet_cmd_strip_relocs = OBJCOPY $@
> > - cmd_strip_relocs = $(OBJCOPY) $(addprefix --remove-section=,$(remove-section-y)) $< $@
> > + cmd_strip_relocs = set -e; \
> > + trap 'rm $<.noload' EXIT HUP INT; \
> > + $(OBJCOPY) $(patsubst %,--set-section-flags %=noload,$(remove-section-y)) $< $<.noload && \
> > + $(OBJCOPY) $(addprefix --remove-section=,$(remove-section-y)) $<.noload $@
> >
> > targets += vmlinux
>
> according to man-page:
>
> If you do not specify outfile, objcopy creates a temporary file and
> destructively renames the result with the name of infile.
>
> That is true even in freebsd:
>
> https://man.freebsd.org/cgi/man.cgi?query=objcopy
>
> Do you want to support any other objcopy implementations ?

yeah, it's actually because I dislike modifying vmlinux.unstripped in
the vmlinux rule.

But it may be that Nathan does not see it this way.

--
Nicolas