X hits on this document





40 / 120

those methods or functions will appear in the .idata (import data) section of the

Windows® PE header. In production versions of a program, the machine code doesn't

directly contain any symbolic information from the original source code--such as method

names, variable names, or line numbers; the executable file only contains the machine

instructions that were produced by the compiler [9]. This lack of information about the

connection between the machine instructions and the original source is unacceptable for

purposes of debugging—this is why most modern compilers, like GCC, include an option

to generate debugging information into the executable file that allow one to trace a failure

occurring at a particular machine instruction back to a line in the original source code [9].

To show the various kinds of symbolic information that are inserted into machine

code to enable debugging of an application, the GNU C++ compiler was directed to

compile the program Calculator.cpp with debugging information but to generate

assembly language instead of machine code. The source code for Calculator.cpp and the

generated assembly language equivalent are given in Table 7.1. The GNU compiler

stores debug information in the symbol tables (.stabs) section of the Windows® PE

header so that it will be loaded into memory as part of the program image. It should be

clear from the generated assembly in Table 7.1 that the debugging information inserted

by GCC is by no means a replacement for the original source code of the program. A

source-level debugger, like the GNU Project Debugger (GDB), must be able to locate the

original source code file to make use of the debugging information embedded in the

executable. Nevertheless, debugging information can give plenty of hints to a reverse


Document info
Document views511
Page views512
Page last viewedSat Jan 21 16:56:50 UTC 2017