From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754709AbcC3PIs (ORCPT <rfc822;w@1wt.eu>);
	Wed, 30 Mar 2016 11:08:48 -0400
Received: from mga03.intel.com ([134.134.136.65]:23318 "EHLO mga03.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753939AbcC3PIq (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 30 Mar 2016 11:08:46 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.24,416,1455004800"; 
   d="scan'208";a="934771150"
Date: Wed, 30 Mar 2016 08:08:44 -0700
From: Andi Kleen <ak@linux.intel.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        linux-kernel@vger.kernel.org, Stephane Eranian <eranian@google.com>,
        Peter Zijlstra <a.p.zijlstra@chello.nl>,
        Thomas Gleixner <tglx@linutronix.de>,
        Andy Lutomirski <luto@kernel.org>,
        Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
        Denys Vlasenko <dvlasenk@redhat.com>, Zi Shen Lim <zlim.lnx@gmail.com>
Subject: Re: [PATCH 10/11] perf tools: Add probing for udev86 library
Message-ID: <20160330150844.GD9083@tassilo.jf.intel.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>
 <20160330135246.GA29990@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160330135246.GA29990@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> 
> Yeah, so udis86 also seems to be a pretty old, relatively stale library with no 
> support for new instructions AFAICS.

There are lots of new instructions in pull requests on github.

But yes the author seems to be a bit slow in pulling.

> 
> 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?

It's a major project. Who is gonna work on it? Are you volunteering?

Longer term I agree it would be reasonable (if someone can be found to work on it),
but short term udis86 is there and works today.

-Andi