linux-toolchains.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chen Zhongjin <chenzhongjin@huawei.com>
To: Ard Biesheuvel <ardb@kernel.org>, Peter Zijlstra <peterz@infradead.org>
Cc: Michael Matz <matz@suse.de>, Borislav Petkov <bp@alien8.de>,
	"Josh Poimboeuf" <jpoimboe@kernel.org>,
	<linux-toolchains@vger.kernel.org>,
	"Indu Bhagat" <indu.bhagat@oracle.com>,
	Nick Desaulniers <ndesaulniers@google.com>,
	<linux-kernel@vger.kernel.org>,
	"Jose E. Marchesi" <jemarch@gnu.org>,
	Miroslav Benes <mbenes@suse.cz>,
	Mark Rutland <mark.rutland@arm.com>,
	"Will Deacon" <will@kernel.org>, <x86@kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<live-patching@vger.kernel.org>, <linuxppc-dev@lists.ozlabs.org>,
	Sathvika Vasireddy <sv@linux.ibm.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	Mark Brown <broonie@kernel.org>
Subject: Re: [RFC] Objtool toolchain proposal: -fannotate-{jump-table,noreturn}
Date: Wed, 21 Sep 2022 11:16:04 +0800	[thread overview]
Message-ID: <f7df65b0-ae41-8cce-01aa-84349efc387a@huawei.com> (raw)
In-Reply-To: <CAMj1kXGa7D6TLOQruYF+0czWwxcRxN7k1rWTrhB2xnjTQ32c9Q@mail.gmail.com>

Hi,

On 2022/9/21 0:49, Ard Biesheuvel wrote:
> On Thu, 15 Sept 2022 at 10:47, Peter Zijlstra <peterz@infradead.org> wrote:
>> On Thu, Sep 15, 2022 at 10:56:58AM +0800, Chen Zhongjin wrote:
>>
>>> We have found some anonymous information on x86 in .rodata.
>> Well yes, but that's still a bunch of heuristics on our side.
>>
>>> I'm not sure if those are *all* of Josh wanted on x86, however for arm64 we
>>> did not found that in the same section so it is a problem on arm64 now.
>> Nick found Bolt managed the ARM64 jumptables:
>>
>>    https://github.com/llvm/llvm-project/blob/main/bolt/lib/Target/AArch64/AArch64MCPlusBuilder.cpp#L484
>>
>> But that does look like a less than ideal solution too.
>>
>>> Does the compiler will emit these for all arches? At lease I tried and
>>> didn't find anything meaningful (maybe I omitted it).
>> That's the question; can we get the compiler to help us here in a well
>> defined manner.
> Do BTI landing pads help at all here? I.e., I assume that objtool just
> treats any indirect call as a dangling edge in the control flow graph,
> and the problem is identifying the valid targets. In the BTI case,
> those will all start with a 'BTI J' instruction.

Maybe not enough, I guess.

For switch jump tables we need to know its *own* jump targets so that we 
can go through all its branches. If there are more than one indirect 
jump inside one function, only marks targets with BTI J can't help 
matching the entry and its targets.


Anyway I think this job is more for compiler. Switch jump tables is 
different from other indirect jump/call. It have fixed control flow just 
as if/else flow and the indirect jump table is just a compiler 
optimization which hide this.


Best,

Chen


  reply	other threads:[~2022-09-21  3:16 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-09 18:07 [RFC] Objtool toolchain proposal: -fannotate-{jump-table,noreturn} Josh Poimboeuf
2022-09-11 15:26 ` Peter Zijlstra
2022-09-11 15:31   ` Ard Biesheuvel
2022-09-12 10:52 ` Borislav Petkov
2022-09-12 14:17   ` Michael Matz
2022-09-14  0:04     ` Josh Poimboeuf
2022-09-14 14:00       ` Peter Zijlstra
2022-09-14 14:28         ` Michael Matz
2022-09-14 14:55           ` Peter Zijlstra
2022-09-14 17:34             ` Segher Boessenkool
2022-09-15  2:56     ` Chen Zhongjin
2022-09-15  8:47       ` Peter Zijlstra
2022-09-20 16:49         ` Ard Biesheuvel
2022-09-21  3:16           ` Chen Zhongjin [this message]
2022-09-12 11:31 ` Segher Boessenkool
2022-09-14 10:21   ` Josh Poimboeuf
2022-09-14 12:08     ` Michael Matz
2022-09-14 12:16     ` Segher Boessenkool
2022-09-13 22:51 ` Indu Bhagat
2022-09-14  0:12   ` Josh Poimboeuf

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=f7df65b0-ae41-8cce-01aa-84349efc387a@huawei.com \
    --to=chenzhongjin@huawei.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=broonie@kernel.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=indu.bhagat@oracle.com \
    --cc=jemarch@gnu.org \
    --cc=jpoimboe@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-toolchains@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=matz@suse.de \
    --cc=mbenes@suse.cz \
    --cc=ndesaulniers@google.com \
    --cc=peterz@infradead.org \
    --cc=sv@linux.ibm.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.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 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).