Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 9 Apr 2019 18:20:28 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Raphael Gault <raphael.gault@arm.com>
Cc:     linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        jpoimboe@redhat.com, catalin.marinas@arm.com, will.deacon@arm.com,
        julien.thierry@arm.com
Subject: Re: [RFC 2/6] objtool: arm64: Add required implementation for
 supporting the aarch64 architecture in objtool.
Message-ID: <20190409162028.GT11158@hirez.programming.kicks-ass.net>
References: <20190409135243.12424-1-raphael.gault@arm.com>
 <20190409135243.12424-3-raphael.gault@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190409135243.12424-3-raphael.gault@arm.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Apr 09, 2019 at 02:52:39PM +0100, Raphael Gault wrote:

> The decoding of the instruction is split into classes and subclasses as described into
> the Instruction Encoding in the ArmV8.5 Architecture Reference Manual.

>  tools/objtool/arch/arm64/decode.c             | 2843 +++++++++++++++++

Oh man, I hope you generated much of that from the ARM64 Instruction Set
Architecture XML files [*]. Otherwise that's been a lot of typing.

Anyway, since you now have that, would it make sense to use this same
decoder in your kernel tree? I found at least one partial decoder in
arch/arm64/kernel/probes/decode-insn.c, but I suspect you have more.

(Note kprobes is how x86 initially grew its instruction decoder IIRC)


* https://developer.arm.com/architectures/cpu-architecture/a-profile/exploration-tools