All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sathvika Vasireddy <sv@linux.ibm.com>
To: linuxppc-dev@lists.ozlabs.org
Cc: jpoimboe@redhat.com, peterz@infradead.org,
	linux-kernel@vger.kernel.org, aik@ozlabs.ru, mpe@ellerman.id.au,
	mingo@redhat.com, christophe.leroy@csgroup.eu,
	rostedt@goodmis.org, mbenes@suse.cz, npiggin@gmail.com,
	chenzhongjin@huawei.com, naveen.n.rao@linux.vnet.ibm.com,
	sv@linux.ibm.com
Subject: [PATCH v6 01/16] powerpc: Fix __WARN_FLAGS() for use with Objtool
Date: Mon, 14 Nov 2022 23:27:39 +0530	[thread overview]
Message-ID: <20221114175754.1131267-2-sv@linux.ibm.com> (raw)
In-Reply-To: <20221114175754.1131267-1-sv@linux.ibm.com>

Commit 1e688dd2a3d675 ("powerpc/bug: Provide better flexibility to
WARN_ON/__WARN_FLAGS() with asm goto") updated __WARN_FLAGS() to use asm
goto, and added a call to 'unreachable()' after the asm goto for optimal
code generation. With CONFIG_OBJTOOL enabled, 'annotate_unreachable()'
statement in 'unreachable()' tries to note down the location of the
subsequent instruction in a separate elf section to aid code flow
analysis. However, on powerpc, this results in gcc emitting a call to a
symbol of size 0. This results in objtool complaining of "unannotated
intra-function call" since the target symbol is not a valid function
call destination.

Objtool wants this annotation for code flow analysis, which we are not
yet enabling on powerpc. As such, expand the call to 'unreachable()' in
__WARN_FLAGS() without annotate_unreachable():
        barrier_before_unreachable();
        __builtin_unreachable();

This still results in optimal code generation for __WARN_FLAGS(), while
getting rid of the objtool warning.

We still need barrier_before_unreachable() to work around gcc bugs 82365
and 106751:
- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106751

Tested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Sathvika Vasireddy <sv@linux.ibm.com>
---
 arch/powerpc/include/asm/bug.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
index 61a4736355c2..ef42adb44aa3 100644
--- a/arch/powerpc/include/asm/bug.h
+++ b/arch/powerpc/include/asm/bug.h
@@ -99,7 +99,8 @@
 	__label__ __label_warn_on;				\
 								\
 	WARN_ENTRY("twi 31, 0, 0", BUGFLAG_WARNING | (flags), __label_warn_on); \
-	unreachable();						\
+	barrier_before_unreachable();				\
+	__builtin_unreachable();				\
 								\
 __label_warn_on:						\
 	break;							\
-- 
2.31.1


WARNING: multiple messages have this Message-ID (diff)
From: Sathvika Vasireddy <sv@linux.ibm.com>
To: linuxppc-dev@lists.ozlabs.org
Cc: peterz@infradead.org, npiggin@gmail.com,
	linux-kernel@vger.kernel.org, aik@ozlabs.ru, mingo@redhat.com,
	sv@linux.ibm.com, rostedt@goodmis.org, jpoimboe@redhat.com,
	naveen.n.rao@linux.vnet.ibm.com, mbenes@suse.cz,
	chenzhongjin@huawei.com
Subject: [PATCH v6 01/16] powerpc: Fix __WARN_FLAGS() for use with Objtool
Date: Mon, 14 Nov 2022 23:27:39 +0530	[thread overview]
Message-ID: <20221114175754.1131267-2-sv@linux.ibm.com> (raw)
In-Reply-To: <20221114175754.1131267-1-sv@linux.ibm.com>

Commit 1e688dd2a3d675 ("powerpc/bug: Provide better flexibility to
WARN_ON/__WARN_FLAGS() with asm goto") updated __WARN_FLAGS() to use asm
goto, and added a call to 'unreachable()' after the asm goto for optimal
code generation. With CONFIG_OBJTOOL enabled, 'annotate_unreachable()'
statement in 'unreachable()' tries to note down the location of the
subsequent instruction in a separate elf section to aid code flow
analysis. However, on powerpc, this results in gcc emitting a call to a
symbol of size 0. This results in objtool complaining of "unannotated
intra-function call" since the target symbol is not a valid function
call destination.

Objtool wants this annotation for code flow analysis, which we are not
yet enabling on powerpc. As such, expand the call to 'unreachable()' in
__WARN_FLAGS() without annotate_unreachable():
        barrier_before_unreachable();
        __builtin_unreachable();

This still results in optimal code generation for __WARN_FLAGS(), while
getting rid of the objtool warning.

We still need barrier_before_unreachable() to work around gcc bugs 82365
and 106751:
- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106751

Tested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Sathvika Vasireddy <sv@linux.ibm.com>
---
 arch/powerpc/include/asm/bug.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
index 61a4736355c2..ef42adb44aa3 100644
--- a/arch/powerpc/include/asm/bug.h
+++ b/arch/powerpc/include/asm/bug.h
@@ -99,7 +99,8 @@
 	__label__ __label_warn_on;				\
 								\
 	WARN_ENTRY("twi 31, 0, 0", BUGFLAG_WARNING | (flags), __label_warn_on); \
-	unreachable();						\
+	barrier_before_unreachable();				\
+	__builtin_unreachable();				\
 								\
 __label_warn_on:						\
 	break;							\
-- 
2.31.1


  reply	other threads:[~2022-11-14 17:59 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-14 17:57 [PATCH v6 00/16] objtool: Enable and implement --mcount option on powerpc Sathvika Vasireddy
2022-11-14 17:57 ` Sathvika Vasireddy
2022-11-14 17:57 ` Sathvika Vasireddy [this message]
2022-11-14 17:57   ` [PATCH v6 01/16] powerpc: Fix __WARN_FLAGS() for use with Objtool Sathvika Vasireddy
2022-11-14 17:57 ` [PATCH v6 02/16] powerpc: Override __ALIGN and __ALIGN_STR macros Sathvika Vasireddy
2022-11-14 17:57   ` Sathvika Vasireddy
2022-11-14 17:57 ` [PATCH v6 03/16] powerpc: Fix objtool unannotated intra-function call warnings Sathvika Vasireddy
2022-11-14 17:57   ` Sathvika Vasireddy
2022-11-14 17:57 ` [PATCH v6 04/16] powerpc: Curb " Sathvika Vasireddy
2022-11-14 17:57   ` Sathvika Vasireddy
2022-11-14 17:57 ` [PATCH v6 05/16] powerpc: Skip objtool from running on drivers/crypto/vmx/aesp8-ppc.o Sathvika Vasireddy
2022-11-14 17:57   ` Sathvika Vasireddy
2022-11-14 17:57 ` [PATCH v6 06/16] powerpc: Fix objtool unannotated intra-function call warnings on PPC32 Sathvika Vasireddy
2022-11-14 17:57   ` Sathvika Vasireddy
2022-11-14 17:57 ` [PATCH v6 07/16] powerpc: Skip objtool from running on VDSO files Sathvika Vasireddy
2022-11-14 17:57   ` Sathvika Vasireddy
2022-11-14 17:57 ` [PATCH v6 08/16] objtool: Fix SEGFAULT Sathvika Vasireddy
2022-11-14 17:57   ` Sathvika Vasireddy
2022-11-14 17:57 ` [PATCH v6 09/16] objtool: Use target file endianness instead of a compiled constant Sathvika Vasireddy
2022-11-14 17:57   ` Sathvika Vasireddy
2022-11-14 17:57 ` [PATCH v6 10/16] objtool: Use target file class size " Sathvika Vasireddy
2022-11-14 17:57   ` Sathvika Vasireddy
2022-11-14 17:57 ` [PATCH v6 11/16] objtool: Add --mnop as an option to --mcount Sathvika Vasireddy
2022-11-14 17:57   ` Sathvika Vasireddy
2022-11-14 17:57 ` [PATCH v6 12/16] objtool: Read special sections with alts only when specific options are selected Sathvika Vasireddy
2022-11-14 17:57   ` Sathvika Vasireddy
2022-11-14 17:57 ` [PATCH v6 13/16] objtool: Use macros to define arch specific reloc types Sathvika Vasireddy
2022-11-14 17:57   ` Sathvika Vasireddy
2022-11-14 17:57 ` [PATCH v6 14/16] objtool: Add arch specific function arch_ftrace_match() Sathvika Vasireddy
2022-11-14 17:57   ` Sathvika Vasireddy
2022-11-14 17:57 ` [PATCH v6 15/16] objtool/powerpc: Enable objtool to be built on ppc Sathvika Vasireddy
2022-11-14 17:57   ` Sathvika Vasireddy
2022-11-14 17:57 ` [PATCH v6 16/16] objtool/powerpc: Add --mcount specific implementation Sathvika Vasireddy
2022-11-14 17:57   ` Sathvika Vasireddy
2022-12-08 13:02 ` [PATCH v6 00/16] objtool: Enable and implement --mcount option on powerpc Michael Ellerman
2022-12-08 13:02   ` Michael Ellerman

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=20221114175754.1131267-2-sv@linux.ibm.com \
    --to=sv@linux.ibm.com \
    --cc=aik@ozlabs.ru \
    --cc=chenzhongjin@huawei.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mbenes@suse.cz \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.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 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.