Question about portability?

[Escapingbug]

Really glad to have a decompiler written in Rust, and it is well organized!

But I'm actually not very into Radare2, so I wonder if it is possible to port other disassemblers to use this project. One of my expectation is Ghidra which has great architecture supports and have a well-defined processor description language.

The question is, how close is this related to radare2? Or can we split that part to separate crates (or workspace?) so it is possible to let other "front" to use the decompiler?

[XVilka]

@Escapingbug in fact that would be quite easy - Radeco uses ESIL as an input (see esil.rs crate). But internally it uses its own LLVM-like RadecoIR. So you can just add an uplifting code to the RadecoIL, and you are good to go.

See this part of the code: https://github.com/radareorg/radeco-lib/tree/master/src/middle

And here is the radeco client, because radeco-lib is the decompilation library, it is similar to the radare2 philosophy - all features are available for using in your own projects.

[XVilka]

If you want to implement the separation - we will be happy to accept the PR. In fact we should probaly also merge other crates in this repo as well: #48

[Escapingbug]

That'll be good. I'll see what I can do on this. Thanks!

[Escapingbug]

One more question on this topic, I see "r2api" and "r2pipe" in the dependencies, could u please tell me how they are used?

[XVilka]

@Escapingbug r2api is just a high-level API on top of r2pipe. R2pipe is being used to get the additional information from the radare2 session - like symbols, function boundaries, etc. Also it was the idea to synchronize the changes between decompiler and radare2:

• Use basic block information from radare #207
• Integration with radare2 #184
• Load flags, comments and symbols #20

Note, I also started to merge all separate but related crates into the one workspace. Here is the work in progress PR: #260