From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754010AbcC3Nwx (ORCPT ); Wed, 30 Mar 2016 09:52:53 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:35901 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753005AbcC3Nwv (ORCPT ); Wed, 30 Mar 2016 09:52:51 -0400 Date: Wed, 30 Mar 2016 15:52:46 +0200 From: Ingo Molnar To: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo , linux-kernel@vger.kernel.org, Andi Kleen , Stephane Eranian , Peter Zijlstra , Thomas Gleixner , Andy Lutomirski , Masami Hiramatsu , Denys Vlasenko , Zi Shen Lim Subject: Re: [PATCH 10/11] perf tools: Add probing for udev86 library Message-ID: <20160330135246.GA29990@gmail.com> References: <1459294889-12148-1-git-send-email-acme@kernel.org> <1459294889-12148-11-git-send-email-acme@kernel.org> <20160330104326.GB4681@gmail.com> <20160330133625.GB2793@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160330133625.GB2793@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Arnaldo Carvalho de Melo wrote: > Em Wed, Mar 30, 2016 at 12:43:27PM +0200, Ingo Molnar escreveu: > > > From: Andi Kleen > > > > Add autoprobing for the udev86 disassembler library. > > > So the typo in the title is confusing, what is 'udev86'? > > > Also, this library does not seem to be available on stock Ubuntu. We should not be > > adding library dependencies that cannot be resolved on major distros: > > Ok, I'll remove, I thought it would be ok because I fired up: > > # dnf install udis86-devel > > On fedora and it installed straight away, but after I started trying to > update my docker images I couldn't find it on debian > experimental/unstable: > Nor even in OpenSuSE: > Or even Mageia: Yeah, so udis86 also seems to be a pretty old, relatively stale library with no support for new instructions AFAICS. So I'd rather encourage librarizing one of the x86 instruction decoders in arch/x86/, and adding pretty-printing functionality to it. The code can already see instruction boundaries, which is the hardest part. That would also be better supported on non-x86 architectures in the long run: triton:~/tip> find arch/ -name insn.c | xargs ls -l -rw-rw-r-- 1 mingo mingo 30244 Mar 29 11:24 arch/arm64/kernel/insn.c -rw-rw-r-- 1 mingo mingo 1347 Dec 8 06:27 arch/arm/kernel/insn.c -rw-rw-r-- 1 mingo mingo 15123 Mar 30 12:31 arch/x86/lib/insn.c Such an in-kernel-repo library could also be used by live kernel debuggers such as kgdb/kdb, oops/crash-time disassembly printout, etc. ... so how about that direction instead? Thank, Ingo