4 ms·

C and C++ are different languages. I only saw C examples. How would you even decompile to C++? The only C++ information you have in the object code is the mangl

by jordigh 12y ago

C and C++ are different languages. I only saw C examples. How would you even decompile to C++? The only C++ information you have in the object code is the mangled names. How do you use that to get C++ code?

_wmd 12y ago
And vtables, rtti data, systematic sequences of ops for invoking base classes, intrinsic/library functions emitted by the compiler in specific situations, exception handling tables, ...
- jordigh 12y ago
  But none of those is something only a C++ compiler would specifically do, right? How would you distinguish a vtable emitted by a C++ compiler from one hand-rolled in C? I suppose you could just offer a reasonable guess. I wonder if decompiled GTK+ code would end up turning into C++.
  - mieko 12y ago
    Most C++ platform ABIs are pretty trivial to recognize. A tool like this could distinguish a C++ binary by looking at its initialization/housekeeping sections, static constructors, __cxa_atexit, exception handling tables, linked libraries, etc. For example, the Itanium C++ ABI (http://mentorembedded.github.io/cxx-abi/ http://mentorembedded.github.io/cxx-abi/, perhaps Itanium's only real legacy) adopted by Linux/ELF and other platforms, leaves a huge amount of fingerprints on a binary. It'd take a very conscious effort, including hand-crafting linker scripts, to generate a C binary that a tool would incorrectly think was C++.
nobotty 12y ago
virtual functions which are very common in C++ are resolved using a specific technique in the machine code which can be taken note of.
pjmlp 12y ago
As some other decompilers do, by having a knowledge pool of specific compilers. Back in the 90's there was one targeted specifically to executables produced by Borland compilers.
userbinator 12y ago
The first C++ compiler (Cfront) compiled from C++ to C. Once you get some C code that does things with structures and function pointers like a C++ compiler would do, I think it's not impossible to turn those back into classes if you can recognise the patterns that a C++ compiler uses to compile C++ constructs like classes, virtual functions, etc.
- jacquesm 12y ago
  It's actually a lot harder than C. There is a roughly 1:1 correspondence between C and assembly. There is no such 1:1 correspondence between assembly and C++.
  - Hemospectrum 12y ago
    > There is a roughly 1:1 correspondence between C and assembly. I'm afraid that hasn't been true for a number of years. Turn on the optimizer and the resulting assembly can be totally unrecognizable as a translation of what you actually wrote. The compiler takes all kinds of steps both to eliminate redundant operations (via CSE, loop unrolling, etc.) and to take advantage of the weird quirks of modern CPU architectures, like out-of-order execution.
    - dwyer 12y ago
      Just yesterday I was debugging a piece of code I was writing. I started with a printf where I suspected a segfault was occurring. printf(...); for (...) {...} The printf never executed. So I fired up gdb and confirmed the segfault was happening where I thought it was, but the for loop was being initialized before the printf. Even with debugging on and optimization off. Could be a bug in clang (I didn't think to try it with gcc), but even so it shows that the way things should work in theory don't necessarily dictate the way they do work in practice.
  - userbinator 12y ago
    There is a roughly 1:1 correspondence between C++ and C, so it's just one more step to go from C to C++. Just off the top of my head... class data fields -> structure members non-static methods (ctors/dtors included) -> functions with an extra 'this' pointer parameter inheritance -> extended structures with matching prefices virtual functions -> structure with function pointers operator overloading -> methods with special names default arguments -> automatically inserted by compiler function overloading -> types encoded in name of function templates -> whatever code they generate exceptions -> special library functions are used, e.g. _CxxThrowException() Some of those don't decompile so well (e.g. template-generated code, although a refactoring tool might be of help), and things like operators and overloaded functions are probably more of a stylistic choice than a difference in the generated code, but for the most part it doesn't look impossible to get some C++ features to show up in decompiled code. (And given that many of the C++-level optimisations revolve around removing unnecessary code, they could make the C to C++ step even easier.)

by jordigh 12y ago

_wmd 12y ago

And vtables, rtti data, systematic sequences of ops for invoking base classes, intrinsic/library functions emitted by the compiler in specific situations, exception handling tables, ...

jordigh 12y ago
But none of those is something only a C++ compiler would specifically do, right? How would you distinguish a vtable emitted by a C++ compiler from one hand-rolled in C? I suppose you could just offer a reasonable guess. I wonder if decompiled GTK+ code would end up turning into C++.
- mieko 12y ago
  Most C++ platform ABIs are pretty trivial to recognize. A tool like this could distinguish a C++ binary by looking at its initialization/housekeeping sections, static constructors, __cxa_atexit, exception handling tables, linked libraries, etc. For example, the Itanium C++ ABI (http://mentorembedded.github.io/cxx-abi/ http://mentorembedded.github.io/cxx-abi/, perhaps Itanium's only real legacy) adopted by Linux/ELF and other platforms, leaves a huge amount of fingerprints on a binary. It'd take a very conscious effort, including hand-crafting linker scripts, to generate a C binary that a tool would incorrectly think was C++.

nobotty 12y ago

virtual functions which are very common in C++ are resolved using a specific technique in the machine code which can be taken note of.

pjmlp 12y ago

As some other decompilers do, by having a knowledge pool of specific compilers. Back in the 90's there was one targeted specifically to executables produced by Borland compilers.

userbinator 12y ago

The first C++ compiler (Cfront) compiled from C++ to C. Once you get some C code that does things with structures and function pointers like a C++ compiler would do, I think it's not impossible to turn those back into classes if you can recognise the patterns that a C++ compiler uses to compile C++ constructs like classes, virtual functions, etc.

jacquesm 12y ago
It's actually a lot harder than C. There is a roughly 1:1 correspondence between C and assembly. There is no such 1:1 correspondence between assembly and C++.
- Hemospectrum 12y ago
  > There is a roughly 1:1 correspondence between C and assembly. I'm afraid that hasn't been true for a number of years. Turn on the optimizer and the resulting assembly can be totally unrecognizable as a translation of what you actually wrote. The compiler takes all kinds of steps both to eliminate redundant operations (via CSE, loop unrolling, etc.) and to take advantage of the weird quirks of modern CPU architectures, like out-of-order execution.
  - dwyer 12y ago
    Just yesterday I was debugging a piece of code I was writing. I started with a printf where I suspected a segfault was occurring. printf(...); for (...) {...} The printf never executed. So I fired up gdb and confirmed the segfault was happening where I thought it was, but the for loop was being initialized before the printf. Even with debugging on and optimization off. Could be a bug in clang (I didn't think to try it with gcc), but even so it shows that the way things should work in theory don't necessarily dictate the way they do work in practice.
- userbinator 12y ago
  There is a roughly 1:1 correspondence between C++ and C, so it's just one more step to go from C to C++. Just off the top of my head... class data fields -> structure members non-static methods (ctors/dtors included) -> functions with an extra 'this' pointer parameter inheritance -> extended structures with matching prefices virtual functions -> structure with function pointers operator overloading -> methods with special names default arguments -> automatically inserted by compiler function overloading -> types encoded in name of function templates -> whatever code they generate exceptions -> special library functions are used, e.g. _CxxThrowException() Some of those don't decompile so well (e.g. template-generated code, although a refactoring tool might be of help), and things like operators and overloaded functions are probably more of a stylistic choice than a difference in the generated code, but for the most part it doesn't look impossible to get some C++ features to show up in decompiled code. (And given that many of the C++-level optimisations revolve around removing unnecessary code, they could make the C to C++ step even easier.)