20

LLVM IR is a fairly high-level, typed bitcode which can be directly executed by LLVM and compiled to JIT on the fly. It would not surprise me if a new executable format or programming language was designed directly on top of LLVM, to be executed as if it were an interpreted language.

In this regard, I am curious as to the state of the art on LLVM decompilation. Because it is a typed bitcode specifically designed to be easy to analyze, one might expect that it is relatively easy to decompile (or at least reassemble into a more readable or logical form).

Googling turns up this BSc thesis which does a relatively rudimentary job, but seemingly few other leads. I might have expected this fellow's supervisor to have done some further research in this area, but it seems his focus is more towards the compiler design area of research.

Are there research projects, commercial prototypes, or even any kinds of active research being done in the field of LLVM decompilation?

nneonneo
  • 1,283
  • 10
  • 15

1 Answers1

17

It's extremely easy to decompile. LLVM for a long time shipped with a CBackend that would convert LLVM into C.

The LLVM that is created by todays frontends (clang) is very amenable to any kind of analysis and understanding that you can think of. So you can probably just use normal LLVM tools (opt, llc) to "decompile" the IR. I find LLVM IR quite readable on its own, but I'm strange.

However, just like compilation of C to assembler, some information is lost or destroyed. Structure field names are gone, forever replaced with indexes. Their types remain though. Control flow, as a concept, remains, there is no confusion of code and data, but functions can be removed because they are dead or inlined. I believe enum values are removed as well. Parameter information to function remains, as do the types of global variables.

There actually is a decent post where an LLVM contributor outlines pitfalls and problems with using their bitcode format in the manner that you suggest. Many people seem to have listened to him, so I'm not sure if we'll ever need to move beyond the tools we currently have for understanding LLVM bitcode...

Andrew
  • 1,522
  • 12
  • 15