[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a3fc4685-9e8d-ebf6-62ca-2e9028753ce8@csgroup.eu>
Date: Tue, 30 Aug 2022 06:15:59 +0000
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Sathvika Vasireddy <sv@...ux.ibm.com>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
CC: "jpoimboe@...hat.com" <jpoimboe@...hat.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"aik@...abs.ru" <aik@...abs.ru>,
"mpe@...erman.id.au" <mpe@...erman.id.au>,
"mingo@...hat.com" <mingo@...hat.com>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"mbenes@...e.cz" <mbenes@...e.cz>,
"npiggin@...il.com" <npiggin@...il.com>,
"chenzhongjin@...wei.com" <chenzhongjin@...wei.com>,
"naveen.n.rao@...ux.vnet.ibm.com" <naveen.n.rao@...ux.vnet.ibm.com>
Subject: Re: [PATCH v2 01/16] powerpc: Replace unreachable() with it's builtin
variant in __WARN_FLAGS()
Le 29/08/2022 à 07:52, Sathvika Vasireddy a écrit :
> objtool is throwing *unannotated intra-function call* warnings in
> .c files with a few instructions that are marked unreachable. The
> problem comes from the annotate_unreachable() macro that is
> called by unreachable(). This annotation is adding a call to a
> function with size 0, and objtool does not add such symbols
> to the rbtree. Due to this reason, find_call_destination() function
> is not able to find the destination symbol for that call.
>
> With the annotation (annotate_unreachable()), gcc seems to
> generate a 'bl' to unreachable symbol with size 0. But with
> the builtin variant of unreachable (__builtin_unreachable()),
> gcc does not emit calls to such symbols and the warnings
> go away. Given that the codegen remains same, and that
> there are no 'bl' instructions to such symbols emitted, fix
> these warnings by replacing unreachable() with it's builtin
> variant in __WARN_FLAGS().
How can you say that the codegen remains the same if with the original
you get stale 'bl' instructions and with the alternative you don't ?
>
> Also, add barrier_before_unreachable() before __builtin_unreachable()
> to work around a gcc bug [1], for the problem reported at [2].
Here my comment was not related to the gcc bug [1] but to gcc bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365 , which was worked
around by commit 173a3efd3edb ("bug.h: work around GCC PR82365 in BUG()")
By chance it also solve the problem [1] as you mention.
>
> [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106751
> [2]: https://lkml.org/lkml/2022/8/25/418
>
> Signed-off-by: Sathvika Vasireddy <sv@...ux.ibm.com>
Reviewed-by: Christophe Leroy <christophe.leroy@...roup.eu>
> ---
> 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; \
Powered by blists - more mailing lists