This will totally fail for optimised code if it is just using object code without debug information.
There is no information in the resulting machine code that can indicate whether some code has been inlined or not.
Basically any optimisations performed by the compiler will throw this decompilation off.
I question whether you can get any real use out of this...
I don't think the market for this is to get the actual original code. It's more like understanding what a particular program does: when you see it on a higher level it's much easier to understand the code than reading raw assembly.
Absolutely... I get that, but its only functional for non-optimised code.
My point is that for anything non-trivial, its not going to be terribly useful. You're still gonna need to understand what really is going on, optimisers mangle the code out of all recognisability for this decompiler.
Unless the Assembly is using clever tricks like code rewriting, it is always possible to at very least decompile into some form of pseudo-code.
Just the fact of giving symbolic names to memory addresses and replacing Assembly opcodes by more meaningful instructions can make wonders trying to understand some code.
I disagree... inlining will remove all evidence that a function call existed. loop unrolling will remove all evidence that a loop existed (potentially).
Those are basic optimisations, comiplers will transform the code out of all recognisability for a decompiler to be worthwhile.
I question whether you can get any real use out of this...