compiled binary - what do disassembled instructions correspond to in C/C++ source (Linux GCC)

Question

sorry about the messy title! Basically here's what I want to know.

This might sound a bit silly but, if you have a disassembled instruction say:

jz 0x8048e1a

and you also have the source code, how do you go about figuring out what this instruction relates to in the source code?

I should probably mention that I am using Intel's PIN as the application that spits out these disassembled instructions, so I know which function/routine these instructions belong to, I just want to be a bit more precise.

Thanks for any help/hints.

Answer 1

If you have the source code (and the means to compile it), you shouldn't be using a decompiler. The compiler is already producing a mapping between the original source code and the assembly instructions; that's what debugging information is.

The easiest way to see it in action is to start the program in the debugger, set a breakpoint, and when that breakpoint hits, switch to the disassembly view. That'll show you the instructions, as well as the source lines which led to them. (If the compiler had optimizations enabled there won't always be a good correspondence between the two, but you can at least see the rudiments.)

You can also tell your compiler to stop after the code generation phase, and output an assembly file instead of object code. Depending on the compiler, you may also be able to get it to annotate the assembly with the source lines; this'll produce similar information to what you can see in the debugger's disassembly view.

The details of how you do all that depend entirely on your IDE. Read its documentation.

Answer 2

If you're using the GCC toolchain, you can use objdump to disassemble and mix with source code:

objdump -S executable > disasm.txt

See the objdump man pages for more options and information.

If you're using a different toolchain, see the docs for that toolchain.

Answer 3

For that specific instruction:

jz 0x8048e1a

• it's a conditional jump, so search your function for an if, for, do/while or ternary expression (?:)
• it jumps if the zero flag is set, but you'll need to check the previous instruction(s) to see what sets that flag. You may be able to line that logic up with one of the branch conditions you identified above
• it jumps to an address - where is it? What does the code at that address do? You may be able to match that up with the contents of a conditional branch.
• what happens if it doesn't branch? You may be able to line that up with a conditional branch (or the implicit jump of a branch not taken)
• note that the compiler/optimizer are allowed to reverse the sense of comparisons and branches, for example to jump to a nested block, and then back

In general:

• if you have the source, compile to assembler and include all the source and line number annotations your compiler supports
  • it may help to do this once with optimization disabled, so you get a fairly clean translation, and then compare this to the optimized version. The intermediate step can help clarify what your optimizer changed.
• if you have the source but can't compile (or don't know the compile flags used), include all the source etc. annotations your disassembler supports instead
• look for distinctive points in the code:
  • function entry and exit are easy to spot
  • calls to out-of-line (especially libc or other library) functions should show up cleanly, and limit the optimizer's ability to reorder at least the function's arguments, and logic dependent on its result
• instruction-step through the code in a debugger, watching both the source line number and the instruction. The line number may jump around crazily if the optimizer has been busy, but it'll give you an idea how the two relate
• just read the source and understand its logic and control flow. Then just read the assembly and understand it's logic and control flow. Then think about how they match up.