multi level IL

[Mandofskii]

Is your feature request related to a problem? Please describe.
I used Binary Ninja before I switch to Ghidra, Binary Ninja had a good feature called BNIL, It decompiles disassembled code to its IL(BNIL) and C pseudocode.
Why I say It was a good feature ? Cause you can see what is happening in code step by step through BNIL levels and it supports SSA that Ghidra doesnt.

Describe the solution you'd like
Implement a multi level iL in Ghidra or add multiple levels to existing P-Code IL.

Describe alternatives you've considered

Additional context

Recommended by @Alom4hdi in #5562

[bdemick]

Take a look at the documentation in the C++ decompiler part of the source tree (you’ll need to use doxygen to generate it). There are multiple refinement stages that PCode goes through that might provide some similar functionality. Using it is definitely not as friendly as Binary Ninja’s ILs.

[LukeSerne]

Implementing multiple IL levels would be a major change to the way the decompiler works, and as such, it seems unlikely to me that it will happen. Ghidra uses p-code (link to documentation) as IL. After the p-code has been generated from the instructions using the information in the Sleigh specification file(s), it is processed by the decompiler. After the decompiler has done its analysis passes, the result is still p-code, but this "refined" form is often called "high p-code". This final version of p-code is then "translated" into the C-like language that is the output of the decompiler.

If you compile a debug version of the decompiler yourself, you can dump this high p-code, although there is an issue (#5545) to add this option to Ghidra's UI as well. Another way to gain insight into the state of the p-code at various stages during the decompilation process would be to use the DecompVis tool I created. It allows you to see how the data flow graph, recovered from the p-code, changes as the various optimisation rules inside the decompiler are applied.

Also, you mention:

Cause you can see what is happening in code step by step through BNIL levels and it supports SSA that Ghidra doesnt.

I'd argue you can already see what is happening as the assembly instructions of the code under analysis execute. In the listing window, you can enable p-code to be shown. That shows the p-code operations generated for every assembly instruction (i.e. the non-optimised version). While this is not the most efficient way to represent what the code under analysis is doing, it certainly is helpful to understand it.

The p-code is transformed into SSA form by the decompiler (specifically, the heritage rule). Unfortunately, this "low p-code in SSA form" is not available from outside the decompiler (see #5137). I think it'd be a good idea to create a feature request that requests this "lowest" p-code in SSA form to be exposed to the Java side. It's probably easier and less work to implement than multiple IL levels, while still being a big improvement and allowing new types of analysis (for example by hooking the raw pcode to an SMT solver to deobfuscate a binary, as suggested in this blog post).