linux-modules.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Schier <nsc@kernel.org>
To: Alexey Gladkov <legion@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>,
	Petr Pavlu <petr.pavlu@suse.com>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Daniel Gomez <da.gomez@samsung.com>,
	linux-kernel@vger.kernel.org, linux-modules@vger.kernel.org,
	linux-kbuild@vger.kernel.org,
	Masahiro Yamada <masahiroy@kernel.org>
Subject: Re: [PATCH v7 3/8] kbuild: keep .modinfo section in vmlinux.unstripped
Date: Thu, 18 Sep 2025 06:08:51 +0200	[thread overview]
Message-ID: <aMuF0zY_3gusK1nz@levanger> (raw)
In-Reply-To: <aMqrrjXZxYXN0zdY@example.org>

On Wed, Sep 17, 2025 at 02:38:06PM +0200, Alexey Gladkov wrote:
> On Wed, Sep 17, 2025 at 01:55:36PM +0200, Nicolas Schier wrote:
> > On Tue, Sep 16, 2025 at 02:42:48PM +0200, Nicolas Schier wrote:
> > > On Tue, Sep 16, 2025 at 01:30:20PM +0200, Alexey Gladkov wrote:
> > ...
> > > > 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
> > 
> > I'd like to suggest another version closer to yours, as mine has several flaws:
> > 
> > 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
> > 
> > 
> > 
> > Rationale (mainly for myself to not walk into that trap too often again):
> > 
> >   * Use ';' instead of '&&' as 'cmd_' is evaluated in a 'set -e'
> >     environment ('cmd') and thus '&&' may hide a possible error exit
> >     code.
> 
> No, it can't hide exit code. The exit code will be correct even if
> ‘set -e’ is not used.
> 
> $ (exit 0) && (exit 2) && (exit 3); echo $?
> 2
> 
> Actually ‘&&’ is protection against the absence of ‘set -e’.

That is correct for such a simple command sequence.

Putting a compound 'command1 && command2' sequence in a cmd_* macro leads to a
mixture of non-comound and compound statements:

    ( set -e; (exit 0) && (exit 2) && (exit 3); printf 'bye\n' ); echo $?

thus we have a case as described in [1, "-e"], so that the exit code 2
gets lost due to the following successful 'printf'.

[1]: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_26


> 
> >   * Create 'vmlinux' already with the first objcopy and let the second
> >     one modify it in order to not need a temporary file; iff one or the
> >     other objcopy exists with an error exit code, the 'set -e + trap'
> >     ('delete-on-interrupt') shell will remove a possibly existing
> >     vmlinux file.
> 
> That makes totally sense. This will avoid a temporary file. I will use it
> in the new version.
> 
> -- 
> Rgrds, legion
> 

-- 
Nicolas

  reply	other threads:[~2025-09-18  4:09 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-18 16:54 [PATCH v7 0/8] Add generated modalias to modules.builtin.modinfo Alexey Gladkov
2025-08-18 16:54 ` [PATCH v7 1/8] s390: vmlinux.lds.S: Reorder sections Alexey Gladkov
2025-08-18 16:54 ` [PATCH v7 2/8] kbuild: always create intermediate vmlinux.unstripped Alexey Gladkov
2025-09-17 11:57   ` Nicolas Schier
2025-08-18 16:54 ` [PATCH v7 3/8] kbuild: keep .modinfo section in vmlinux.unstripped Alexey Gladkov
2025-09-15  5:56   ` Nicolas Schier
2025-09-16  7:12     ` Alexey Gladkov
2025-09-16  9:36       ` Nicolas Schier
2025-09-16 11:30         ` Alexey Gladkov
2025-09-16 12:42           ` Nicolas Schier
2025-09-16 13:03             ` Alexey Gladkov
2025-09-16 13:28               ` Nicolas Schier
2025-09-17  1:10                 ` Nathan Chancellor
2025-09-17  6:49                   ` Alexey Gladkov
2025-09-17 11:55             ` Nicolas Schier
2025-09-17 12:38               ` Alexey Gladkov
2025-09-18  4:08                 ` Nicolas Schier [this message]
2025-08-18 16:54 ` [PATCH v7 4/8] kbuild: extract modules.builtin.modinfo from vmlinux.unstripped Alexey Gladkov
2025-09-17 11:57   ` Nicolas Schier
2025-08-18 16:54 ` [PATCH v7 5/8] scsi: Always define blogic_pci_tbl structure Alexey Gladkov
2025-08-18 16:55 ` [PATCH v7 6/8] modpost: Add modname to mod_device_table alias Alexey Gladkov
2025-09-14 20:07   ` Nicolas Schier
2025-08-18 16:55 ` [PATCH v7 7/8] modpost: Create modalias for builtin modules Alexey Gladkov
2025-08-18 16:55 ` [PATCH v7 8/8] kbuild: vmlinux.unstripped should always depend on .vmlinux.export.o Alexey Gladkov
2025-10-02 16:37   ` ChaosEsque Team

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=aMuF0zY_3gusK1nz@levanger \
    --to=nsc@kernel.org \
    --cc=da.gomez@samsung.com \
    --cc=legion@kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=nathan@kernel.org \
    --cc=petr.pavlu@suse.com \
    --cc=samitolvanen@google.com \
    /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;
as well as URLs for NNTP newsgroup(s).