Question / discussion about the future of Boomerang

[ceeac]

Hello,

I'm opening this issue here since this still seems to be the most popular Boomerang repository.

For the past months I have been refactoring/writing tests/fixing bugs in my fork of Boomerang here (Changelog). This is still a work in progress, however I would like to spark a discussion on how to best revive the project.

I would be happy to merge my changes back to this repository; I can make a PR if that is the outcome of this discussion.

What are your opinions on this matter?

[reductor]

Nice list of changes, it would be good to see this revived again

[nemerle]

Agreed, it would be awesome if the boomerang was revived.
Question is, what would be the project's direction, since there are a few active decompiler projects now ?
https://github.com/avast-tl/retdec - restricted to a small set of 32 bit architectures.
https://github.com/uxmal/reko

[ceeac]

The problem with RetDec is that it suffers from serious memory allocation issues; I was unable to decompile anything serious without it exhausing all of my RAM and swap (>200 GB).
For Reko, it did not even properly decompile most of the x86 samples Boomerang ships with when I tried it; same for SmartDec/Snowman.

My point is that currently no generally available decompiler (except maybe IDA, I don't have access to it, though) I tried, including Boomerang, is issue-free when it comes to automatic decompilation or even human-assisted decompilation (not that I expected no issues when tackling such a hard problem as machine code decompilation).
So Boomerang is not so much behind the times as one would think given there has not been a proper release in more than ten years.

What I am planning to do now (in chronological order):

• Fix remaining issues with the SPARC decoder/frontend (I mentioned them in Tagged release? ceeac/boomerang#1)
• Fix any remaining small issues that creep up
• Release 0.4.0
• Finish the Capstone x86 decoder (in the capstone branch) and replace the other decoders by Capstone-based decoders
• Replace the old parsers. There is already an implementation for an SSL parser based on flexc++/bisonc++ in the parsers branch, but I'm likely going to abandon it, since it does not work neither with clang nor with MSVC. I'm not even sure whether it works with C++17, either.
• Do another round of bug fixing/cleanup
• Release 0.5.0

After that, I haven't really decided what to do yet. However, those items are high on my eternal to-do list:

• hot-save/hot-reload (save/reload while the decompilation is running). This might even be in a format that other decompilers can understand; I haven't yet investigated how feasible this is, though.
• Implement a better high level code generator based on the No More Gotos paper
• Implement better function detection based on e.g. Nucleus, maybe combined with Function Interface Analysis
• Refactor SSL IR into something that does not need any hard-coded decoder hacks e.g. for call or jump instructions.
• Proper multicore support
• C++ decompilation, including RTTI, vtables etc.

Hopefully this cleared up some of your questions. :)

[nemerle]

This looks like a big bag of goodies for all of us,
As You've probably noticed, I have moved this repository to BoomerangDecompiler 'organization', I'll add You to it, feel free to merge your changes into it as well :)

[uxmal]

Give me a holler when you want to discuss file formats for decompiler interoperability.

[PyroSamurai]

Finally! Boomerang definitely needs its own organization.

[ceeac]

@uxmal Sure.
@nemerle Thanks. I'll merge my changes now; afterwards I'll go through all the old issues and close them if they don't apply any more.

Edit: Doesn't seem that I have push access yet. I wanted to push develop directly and work from there. Or should I make a PR to another branch @nemerle ?

[ceeac]

I have now pushed my changes and finished updating all the issues.
@nemerle Could you please update the default branch to develop so the changes are more widely visible?

[nemerle]

@ceeac done :)