Re: [RFC] Objtool toolchain proposal: -fannotate-{jump-table,noreturn}

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On 2022/9/21 0:49, Ard Biesheuvel wrote:
On Thu, 15 Sept 2022 at 10:47, Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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:

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.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux