All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Schier <nsc@kernel.org>
To: Sathvika Vasireddy <sv@linux.ibm.com>
Cc: linux-kbuild@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	nathan@kernel.org, masahiroy@kernel.org, kees@kernel.org,
	naveen@kernel.org, jpoimboe@kernel.org, peterz@infradead.org,
	npiggin@gmail.com, maddy@linux.ibm.com,
	segher@kernel.crashing.org, christophe.leroy@csgroup.eu,
	mingo@kernel.org, mpe@ellerman.id.au, mahesh@linux.ibm.com
Subject: Re: [RFC PATCH v2 2/3] kbuild: Add objtool integration for PowerPC feature fixups
Date: Sat, 4 Oct 2025 21:43:23 +0200	[thread overview]
Message-ID: <aOF4223Q5egUS_in@levanger> (raw)
In-Reply-To: <20250929080456.26538-3-sv@linux.ibm.com>

On Mon, Sep 29, 2025 at 01:34:55PM +0530, Sathvika Vasireddy wrote:
> Add build system support for PowerPC feature fixup processing:
> 
> - Add HAVE_OBJTOOL_FTR_FIXUP config option for architectures that support
>   build-time feature fixup processing
> - Integrate objtool feature fixup processing into vmlinux build
> 
> Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
> Signed-off-by: Sathvika Vasireddy <sv@linux.ibm.com>
> ---
>  Makefile                 |  7 +++++++
>  arch/Kconfig             |  3 +++
>  scripts/Makefile.lib     |  5 +++--
>  scripts/Makefile.vmlinux | 13 ++++++++++++-
>  4 files changed, 25 insertions(+), 3 deletions(-)
> 
...
> diff --git a/arch/Kconfig b/arch/Kconfig
> index d1b4ffd6e085..d870aab17cba 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -1334,6 +1334,9 @@ config HAVE_UACCESS_VALIDATION
>  	bool
>  	select OBJTOOL
>  
> +config HAVE_OBJTOOL_FTR_FIXUP

For me, FTR is not that natural to parse.  Is there a reason for using
FTR instead of FEATURE?

...
> diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux
> index b64862dc6f08..94cc2bba929a 100644
> --- a/scripts/Makefile.vmlinux
> +++ b/scripts/Makefile.vmlinux
> @@ -84,7 +84,8 @@ ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(SRCARCH)/Makefile.postlink)
>  # Final link of vmlinux with optional arch pass after final link
>  cmd_link_vmlinux =							\
>  	$< "$(LD)" "$(KBUILD_LDFLAGS)" "$(LDFLAGS_vmlinux)" "$@";	\
> -	$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
> +	$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)	\
> +	$(cmd_objtool_vmlinux)
>  
>  targets += $(vmlinux-final)
>  $(vmlinux-final): scripts/link-vmlinux.sh vmlinux.o $(KBUILD_LDS) FORCE
> @@ -131,3 +132,13 @@ existing-targets := $(wildcard $(sort $(targets)))
>  -include $(foreach f,$(existing-targets),$(dir $(f)).$(notdir $(f)).cmd)
>  
>  .PHONY: $(PHONY)
> +
> +# objtool for vmlinux
> +# ----------------------------------
> +#
> +#  For feature fixup, objtool does not run on individual
> +#  translation units. Run this on vmlinux instead.
> +
> +ifdef CONFIG_HAVE_OBJTOOL_FTR_FIXUP
> +cmd_objtool_vmlinux = ; $(objtool) --ftr-fixup --link $@

This cmd_* definition is broken as $(call cmd,objtool_vmlinux) would be
evaluated to '... ; ; ...' (shell syntax error).

What about putting the objtool call right into cmd_link_vmlinux?


cmd_link_vmlinux =							\
	$< "$(LD)" "$(KBUILD_LDFLAGS)" "$(LDFLAGS_vmlinux)" "$@";	\
	$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true);   \
	$(if $(CONFIG_HAVE_OBJTOOL_FTR_FIXUP), $(objtool) --ftr-fixup --link $@, true)


Kind regards,
Nicolas

  reply	other threads:[~2025-10-04 19:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-29  8:04 [RFC PATCH v2 0/3] objtool: Fixup alternate feature relative addresses Sathvika Vasireddy
2025-09-29  8:04 ` [RFC PATCH v2 1/3] objtool/powerpc: Enhance objtool to fixup " Sathvika Vasireddy
2025-09-29 10:49   ` Peter Zijlstra
2025-09-29 16:59     ` Sathvika Vasireddy
2025-10-02 13:46   ` kernel test robot
2025-09-29  8:04 ` [RFC PATCH v2 2/3] kbuild: Add objtool integration for PowerPC feature fixups Sathvika Vasireddy
2025-10-04 19:43   ` Nicolas Schier [this message]
2025-10-13  1:07     ` Sathvika Vasireddy
2025-09-29  8:04 ` [RFC PATCH v2 3/3] powerpc: Enable build-time feature fixup processing by default Sathvika Vasireddy

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=aOF4223Q5egUS_in@levanger \
    --to=nsc@kernel.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=jpoimboe@kernel.org \
    --cc=kees@kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=mahesh@linux.ibm.com \
    --cc=masahiroy@kernel.org \
    --cc=mingo@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=nathan@kernel.org \
    --cc=naveen@kernel.org \
    --cc=npiggin@gmail.com \
    --cc=peterz@infradead.org \
    --cc=segher@kernel.crashing.org \
    --cc=sv@linux.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.