Re: [RFC v5 00/57] objtool: Add support for arm64

[Julien Thierry]

On 1/21/20 10:30 AM, Will Deacon wrote:
> On Thu, Jan 09, 2020 at 04:02:03PM +0000, Julien Thierry wrote:
> > This patch series is the continuation of Raphael's work [1]. All the
> > patches can be retrieved from:
> > git clone -b arm64-objtool-v5 https://github.com/julien-thierry/linux.git
>
> [...]
>
> >    objtool: arm64: Decode unknown instructions
> >    objtool: arm64: Decode simple data processing instructions
> >    objtool: arm64: Decode add/sub immediate instructions
> >    objtool: arm64: Decode logical data processing instructions
> >    objtool: arm64: Decode system instructions not affecting the flow
> >    objtool: arm64: Decode calls to higher EL
> >    objtool: arm64: Decode brk instruction
> >    objtool: arm64: Decode instruction triggering context switch
> >    objtool: arm64: Decode branch instructions with PC relative immediates
> >    objtool: arm64: Decode branch to register instruction
> >    objtool: arm64: Decode basic load/stores
> >    objtool: arm64: Decode load/store with register offset
> >    objtool: arm64: Decode load/store register pair instructions
> >    objtool: arm64: Decode FP/SIMD load/store instructions
> >    objtool: arm64: Decode load/store exclusive
> >    objtool: arm64: Decode atomic load/store
> >    objtool: arm64: Decode pointer auth load instructions
> >    objtool: arm64: Decode load acquire/store release
> >    objtool: arm64: Decode load/store with memory tag
> >    objtool: arm64: Decode load literal
> >    objtool: arm64: Decode register data processing instructions
> >    objtool: arm64: Decode FP/SIMD data processing instructions
> >    objtool: arm64: Decode SVE instructions
>
> That's a lot of decoding logic which we already have in
> arch/arm64/{kernel/insn.c,include/asm/insn.h}. I'd prefer to see this stuff
> reused or generated from a single source, since it's really easy to get it
> wrong, has a tendency to bitrot and is nasty to debug.

The thing is that the code in those files is mostly encoding logic 
(motivated by BPF) rather than decoding (except for the instruction that 
might be trapped, but these rarely overlap with instructions that 
objtools cares about). I agree that ideally the decoding/encoding should 
be under arch/arm64/lib, I was just a bit weary introducing a lot of 
decoding code under arch/arm64 that wouldn't even be used in kernel code.

But I can make an attempt for the encode/decode lib and post it as part 
of the next version.

Cheers,

--
Julien Thierry