Dear Sir,
What do you want to do ?.
- Gcc, especially when the optimizers are turned on, heavily optimizes
the source code.
If you want to reverse-engineer, in order to recognize the C-source
in the assembly,
some suggestions:
1. Turn on the debug option. Then, GCC annotates the assembly
introducing info as to which
assembly statement belongs to which source line. It may not work
with the optimizer on.
2. Run the compiler with -fdump-all. Then, it outputs a lot of verbose
files, documenting how
the compile and optimizations have been done. It includes all the
restructuring, and also
the register allocation. Now, good luck with that, it are long and
difficult to read files.
Best Regards,
Henri.
On 11/12/20 6:04 AM, visitor x via Gcc-help wrote:
Thank you for the pointer.
I learned SSA and realized that the problem is more challenging than I thought. As far, my understanding of SSA is that compilers restrict the definition site of each variable to only one by introducing phi-function and other tools. In this way it facilitates data flow analysis and further optimization such as dead code elimination.
My idea before is to list all possible manners that compilers assign variables to registers, then it may be easier to recover variables from binary. Now it seems to be an impossible mission. So I rethink my ultimate goal, essentially a track to variable access sequence, which doesn’t require full decompilation (maybe).
All we need to know is whether two instructions access the same variable (or say object if compilers care about only values). It sounds like an alias analysis in binary. Is it a specialized subfield in program/binary analysis?
