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