From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "aik@ozlabs.ru" <aik@ozlabs.ru>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"mingo@redhat.com" <mingo@redhat.com>,
Sathvika Vasireddy <sv@linux.ibm.com>,
"jpoimboe@redhat.com" <jpoimboe@redhat.com>,
"paulus@samba.org" <paulus@samba.org>,
"naveen.n.rao@linux.vnet.ibm.com"
<naveen.n.rao@linux.vnet.ibm.com>,
"mbenes@suse.cz" <mbenes@suse.cz>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [RFC PATCH v3 11/12] powerpc: Remove unreachable() from WARN_ON()
Date: Mon, 4 Jul 2022 12:44:30 +0000 [thread overview]
Message-ID: <1d0c5ebc-3f66-f6cb-998f-072bceb41c5c@csgroup.eu> (raw)
In-Reply-To: <YsLXkCMtQpxmDhVM@hirez.programming.kicks-ass.net>
Le 04/07/2022 à 14:05, Peter Zijlstra a écrit :
> On Sat, Jun 25, 2022 at 06:46:54AM +0000, Christophe Leroy wrote:
>>
>>
>> Le 24/06/2022 à 20:32, Sathvika Vasireddy a écrit :
>>> objtool is throwing *unannotated intra-function call*
>>> warnings with a few instructions that are marked
>>> unreachable. Remove unreachable() from WARN_ON()
>>> to fix these warnings, as the codegen remains same
>>> with and without unreachable() in WARN_ON().
>>
>> Did you try the two exemples described in commit 1e688dd2a3d6
>> ("powerpc/bug: Provide better flexibility to WARN_ON/__WARN_FLAGS() with
>> asm goto") ?
>>
>> Without your patch:
>>
>> 00000640 <test>:
>> 640: 81 23 00 84 lwz r9,132(r3)
>> 644: 71 29 40 00 andi. r9,r9,16384
>> 648: 40 82 00 0c bne 654 <test+0x14>
>> 64c: 80 63 00 0c lwz r3,12(r3)
>> 650: 4e 80 00 20 blr
>> 654: 0f e0 00 00 twui r0,0
>>
>> 00000658 <test9w>:
>> 658: 2c 04 00 00 cmpwi r4,0
>> 65c: 41 82 00 0c beq 668 <test9w+0x10>
>> 660: 7c 63 23 96 divwu r3,r3,r4
>> 664: 4e 80 00 20 blr
>> 668: 0f e0 00 00 twui r0,0
>> 66c: 38 60 00 00 li r3,0
>> 670: 4e 80 00 20 blr
>
> Per this construct you should do as x86 does and assume twui terminates
> control flow and explicitly annotate the WARN case. That is, given the
> fact that BUG as no instructions following it, you can't very well
> annotate that.
That exactly the problem I guess. I'm fine with replacing the
unreachable() by __builtin_unreachable() with our __WARN_FLAGS() and
BUG() but we will still have a problem with some of the unrachable()
that are in core parts of the kernel.
Even the ones in arch/powerpc/, they are valid and should remain. The
point seems that the generic annotate_unreachable() is wrong for powerpc
as is, and activating CONFIG_OBJTOOL lead to bad code generation.
By the way, for which functionnalities of objtool is that analysis
necessary ? I understand it is not necessary to mcount accounting, so
maybe the not empty annotate_unreachable() should be limited to those
those functionnalities ?
>
> Alternatively, you can teach objtool to look at __bug_table to
> distinguish these cases.
Isn't it enough to tell objtool that execution never go past twui, using
INSN_BUG ?
By the way, for __WARN_FLAGS, we use the __extable for the continuation.
Is objtools able to follow __extable ?
Christophe
next prev parent reply other threads:[~2022-07-04 12:45 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-24 18:32 [RFC PATCH v3 00/12] objtool: Enable and implement --mcount option on powerpc Sathvika Vasireddy
2022-06-24 18:32 ` [RFC PATCH v3 01/12] objtool: Fix SEGFAULT Sathvika Vasireddy
2022-07-08 15:10 ` Christophe Leroy
2022-06-24 18:32 ` [RFC PATCH v3 02/12] objtool: Use target file endianness instead of a compiled constant Sathvika Vasireddy
2022-06-24 18:32 ` [RFC PATCH v3 03/12] objtool: Use target file class size " Sathvika Vasireddy
2022-07-08 17:35 ` Christophe Leroy
2022-06-24 18:32 ` [RFC PATCH v3 04/12] objtool: Add --mnop as an option to --mcount Sathvika Vasireddy
2022-06-24 18:32 ` [RFC PATCH v3 05/12] powerpc: Skip objtool from running on VDSO files Sathvika Vasireddy
2022-06-24 18:32 ` [RFC PATCH v3 06/12] objtool: Read special sections with alts only when specific options are selected Sathvika Vasireddy
2022-06-24 18:32 ` [RFC PATCH v3 07/12] objtool: Use macros to define arch specific reloc types Sathvika Vasireddy
2022-07-04 11:14 ` Peter Zijlstra
2022-07-04 15:53 ` Christophe Leroy
2022-07-04 16:18 ` Peter Zijlstra
2022-06-24 18:32 ` [RFC PATCH v3 08/12] objtool: Add arch specific function arch_ftrace_match() Sathvika Vasireddy
2022-06-24 18:32 ` [RFC PATCH v3 09/12] objtool/powerpc: Enable objtool to be built on ppc Sathvika Vasireddy
2022-06-24 18:32 ` [RFC PATCH v3 10/12] objtool/powerpc: Add --mcount specific implementation Sathvika Vasireddy
2022-06-24 18:32 ` [RFC PATCH v3 11/12] powerpc: Remove unreachable() from WARN_ON() Sathvika Vasireddy
2022-06-25 6:46 ` Christophe Leroy
2022-06-27 15:21 ` Sathvika Vasireddy
2022-06-27 15:35 ` Sathvika Vasireddy
2022-06-27 15:46 ` Christophe Leroy
2022-06-29 18:30 ` Christophe Leroy
2022-06-30 8:05 ` Naveen N. Rao
2022-06-30 9:58 ` Christophe Leroy
2022-06-30 10:33 ` Christophe Leroy
2022-06-30 10:37 ` Naveen N. Rao
2022-06-30 15:58 ` Segher Boessenkool
2022-07-04 12:01 ` Peter Zijlstra
2022-07-04 11:43 ` Peter Zijlstra
2022-07-01 2:13 ` Chen Zhongjin
2022-07-01 6:56 ` Sathvika Vasireddy
2022-07-01 11:40 ` [RFC PATCH v3 11/12] powerpc: Remove unreachable() from WARN_ON() (gcc issue ?) Christophe Leroy
2022-07-04 11:45 ` [RFC PATCH v3 11/12] powerpc: Remove unreachable() from WARN_ON() Peter Zijlstra
2022-07-04 12:34 ` Christophe Leroy
2022-07-05 15:48 ` Segher Boessenkool
2022-07-04 12:05 ` Peter Zijlstra
2022-07-04 12:44 ` Christophe Leroy [this message]
2022-07-04 14:19 ` Peter Zijlstra
2022-06-24 18:32 ` [RFC PATCH v3 12/12] objtool/powerpc: Fix unannotated intra-function call warnings Sathvika Vasireddy
2022-07-08 15:06 ` [RFC PATCH v3 00/12] objtool: Enable and implement --mcount option on powerpc Christophe Leroy
2022-07-08 15:42 ` Christophe Leroy
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=1d0c5ebc-3f66-f6cb-998f-072bceb41c5c@csgroup.eu \
--to=christophe.leroy@csgroup.eu \
--cc=aik@ozlabs.ru \
--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=naveen.n.rao@linux.vnet.ibm.com \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.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 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).