[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A390C5C.9020606@redhat.com>
Date: Wed, 17 Jun 2009 11:31:40 -0400
From: Masami Hiramatsu <mhiramat@...hat.com>
To: Tim Abbott <tabbott@...lice.com>
CC: Ingo Molnar <mingo@...e.hu>,
Ananth N Mavinakayanahalli <ananth@...ibm.com>,
lkml <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Jim Keniston <jkenisto@...ibm.com>,
Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
Christoph Hellwig <hch@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
Anders Kaseorg <andersk@...lice.com>,
systemtap <systemtap@...rces.redhat.com>,
DLE <dle-develop@...ts.sourceforge.net>
Subject: Re: [RFC][ PATCH -tip 0/6] kprobes: Kprobes jump optimization support
Masami Hiramatsu wrote:
>> udis86 generates all its instruction table data from an XML opcode file,
>> which is I think what H. Peter Anvin was suggesting you should do in this
>> previous thread on your instruction decoder:
>> <http://lkml.indiana.edu/hypermail/linux/kernel/0904.0/01929.html>
>> Compared to e.g. libopcodes it is still quite small -- there's a total of
>> about 3000 lines of C, plus some instruction tables that are automatically
>> generated from an XML description of the instructions.
>
> I'm not so sure about udis86. Can I use it in exception path (and kprobes)?
> Is that XML things enough easy to be maintained?
And one big question is that who needs full featured disassembler in kernel.
It seems that kprobes and other potential user only need an instruction
decoder (and an instruction emulator too.)
Thank you,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division
e-mail: mhiramat@...hat.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists