Windows program Debugging Series: Using VC + + to generate debugging information to turn

  Windows program Debugging Series: Using VC + + to generate debug information zhangtao,[email protected], translated from "Generating debug information with Visual C + +", Oleg Star Odumov Source: http://www.cnblogs.com/itrust/archive/2006/08/17/479603.aspx Introduction When we use the debugger to debug a program, we want to be able to step into the source code, set breakpoints in code , observe the value of the variable (including the value of the user-defined complex type). However, the executable file contains only the raw byte data-the header information and table information used by the machine instructions and the operating system execution program. After the operating system loads and runs the executable file, it uses different fragments of memory (stacks, heaps) to hold the data according to different requirements, where the raw byte data remains. So how does the debugger know which line of code the current CPU instruction corresponds to? How do I know the local variables for which function the address in the stack corresponds? The answer is "debug information," which is a bridge between the high-level programming language and the raw byte data that runs the program. Noun Interpretation location: There are different meanings in different situations. For functions, it is the address of the first byte of a function, the first byte of a variable in memory for global and static variables, and, for local and function arguments, is usually the offset of the first byte of the variable relative to the predefined base address of the function stack. In addition, other types of locations may appear, such as: registers, TLS slots (see: http://www.blogcn.com/u2/38/94/silannyukun/blog/37069531.html), metadata tokens (metadata   token, see http://naoku.net/blogs/framesniper/archive/2005/04/12/1910.aspx). FPO (frame pointer omission): frame pointer omitted, FPO used to link CodeView or PDB symbols. It helps the debugger find the parameters and local variables for the function in the place where the compiler does not generate a standard stack frame with the EBP register. Types of debug information we only discuss the existing Microsoft-provided debuggers on the Intel X86 platform. Type description of information public functions and variables are used to describe functions and variables that are visible in multiple compilation units (source code files), where the debug information holds each function and variable (location) and name. Private functions and variables are used to describe all functions and variables except public functions and variables, including static functions, static and local variables, function parameters, and debug information to hold the position, size, and name of each function and variable. Source files and code line information are used to map each line of code to a location in the executable file. Of course, some lines of code cannot be mapped, such as comment lines, and such lines of code are not reflected in debugging information. Type information is used to store the type information for each function and variable. For variables or function arguments, type information can tell the debugger whether it is an integer or a string type, or a user-defined type. For a function, the type information records the number of parameters, the type of the call transformation, and the return value. FPO information for FPO-optimized functions, the debug information holds some data to help the debugger determine the size of the function stack frame, even when the frame pointer is invalid. If there is no FPO information, the debugger does not correctly display the call stack of the program being optimized. Edit and Continue execution information is used to help the visual Studio IDE implement editing and continuation of the functional debugging information format for debugging purposes now to explore how debugging information is stored. Over the past decade, Microsoft development tools have used several different formats to package debug information. Here we discuss the most extensive PDB (program Database) format for COFF, CodeView, and applications. In discussing each format, we start with the following features: What types of debugging information can be saved in this format? Where exactly is the debug information stored (in an executable file, or a separate file)? Is there a document description for this format? COFF COFF is the oldest of all the formats involved here, it can only hold three debug messages: public functions and variables, source files and code line information, FPO information. COFF is always saved in the executable file and cannot be saved separately in other files.    documentation for this format see: Microsoft Portable Executable and Common Object file format specification. CodeView CodeView is a more coff and more complex format that can store all types of debugging information except editing and continuing execution information. CodeView is usually saved in an executable file, and it can also be exported from an executable file to a separate file (. DGB file). CodeView documentation can be found in the vc++5.0 symbol Debug Information specification (Symbolic Debug Information Specification) in MSDN. Program database This is the latest debug information format in three kinds, which can store all types of debugging information (including editing and continuing execution information), and also support incremental compilation (the remaining twoFormat is not supported). The program database information is saved in a separate. PDB file. Unfortunately, Microsoft does not provide documentation for the program database format and only provides special programming interfaces Dbghelp and DIA to access it. Currently, there are two versions of the program database format, the first version (PDB2.0) is used by VC6.0, and the second version (PDB 7.0) is used by Visual Studio.NET. PDB 7.0 cannot be up-compatible, which means that VC6.0 cannot read the PDB 7.0 format. Three formats are compared as follows: Does the format have a document store public functions and variables private functions and variable source files and code line information type information FPO information Edit and continue execution information COFF there are executables in the +-+-+-codeview part of the executable file or. DBG file + + + + +-program Database None. PDB file + + + + + + Build Debug information Construction (build) procedure a typical executable file is constructed with two steps: Compile and link. First, the compiler parses the source file, generates machine instructions (saved in the. obj object file), and then the linker merges all available object files into the final executable file. In addition to the object file, the linker also uses library files (library files are also collections of other object files). The entire construction process, such as: if we want to generate debug information for an executable file, we have to go through two steps: First, the compiler creates debug information for each source file, and then the linker merges debug information created by the compiler, such as: By default, the compiler and linker do not produce debug information.    So we have to use compile and link options to ask the compiler and linker to generate debug information, and we can specify which types of debug information to build, what debug Information format to store, and where to save the debugging information. Next, I'll discuss specific compiler and linker options. The Visual C + + 6.0 compiler compiler has the following options:/ZD generates debug information in the COFF format, saves debug information in the object file/z7 generate CodeView format, saves debug information in the object file/zi the generated program database format, and saves it in. In the PDB file,/ZI is basically consistent with/zi, except that the/zi and/ZI options generate a PDB file named vc60.pdb when the debug information contains the edit and continue execution information defaults, or you can use/FD to specify the file name. The option format stores the file contents/zd COFF. OBJ common functions and variable source files and code line information FPO information/z7 CodeView. OBJ public functions and variable private lettersNumber and variable source file and code line information type information FPO information/zi program Database. PDB public functions and variables private functions and variable source files and code line information type information FPO information/zi program Database. PDB public functions and variables private functions and variable source files and code line information type information FPO Edit and Continue execution information linker linker The following options are available:/debug tells the linker to generate debug information, and if this option is not used, all other options are invalid/debugtype specify The possible usages include:/debugtype:coff COFF format. Note: Under this option, the debug information does not contain the source file and the code line information/DEBUGTYPE:CV CodeView or the program database format. What is the format, determined by/pdb/debugtype:both to use both the COFF format and the codeview/program database format/pdb decide whether to CodeView or program database format. /pdb:none represents the CodeView format,/pdb:filename (such as/pdb:myexe.pdb) represents the use of the program database format, and the file name is myexe.pdb. Under the/debugtype:coff option, the/PDB option is not valid. /pdbtype This option is only stored in a separate PDB file for debugging information for one or more object files or library files. The/pdbtype:sept option allows debugging information to be kept in its own PDB file, which speeds up the link speed, which is detrimental to debugging information dispersion and requires multiple PDB files for debugging. In contrast, the/pdbtype:con option allows all debug information to be saved in the final PDB file corresponding to the executable file. To make it easier to understand the pairing of each option, see the following table:/debugtype/pdb format store coff/pdb:none (invalid) COFF Coff/pdb:filename (invalid) COFF in an executable file Cv/pdb:none CodeView cv/pdb:filename Program Database in the executable file. PDB files Both/pdb:none COFF and CodeView in the executable both/pdb:filename COFF and program Database COFF letterIn the executable file, the program database information is in the. The following options are available in the PDB file in the Visual C++.net (2002 and 2003) compiler Compiler:/z7 generate debug information in CodeView format, save in object file/zd,/zi, and/zi all represent debug information in the build program database format. Saved in. PDB file. The difference is the content of the debug information (see table below). By default, the/zd,/zi and/zi options generate a PDB file named vc70.pdb or vc71.pdb, or you can use/FD to specify a file name. Note: The Vc++.net compiler is not COFF. The option format stores content/z7 CodeView. OBJ public functions and variables private functions and variable source files and code line information type information FPO information/ZD program Database. PDB common functions and variable source files and code line information FPO Information/zi program Database. PDB public functions and variables private functions and variable source files and code line information type information FPO information/zi program Database. PDB public functions and variables private functions and variable source files and code line information type information FPO Edit and Continue execution information linker linker The following options are available:/debug tells the linker to generate debug information, and if this option is not used, all other options are invalid. The format of the debug information is always in the program database format and is saved in the PDB file. By default, the linker uses the executable file name to generate the PDB file name. The PDB file name can contain variable content for all debugging information. /PDB Specifies the PDB file name. /pdbstripped allows the linker to generate additional PDB files that are scoped to: public functions and variables FPO information Note: COFF and CodeView formats are not VC + +. NET linker support. debugging information of Static library because there is no connection process, the debugging information of Static library is more simple than the executable file.     Regardless of the compiler version (VC6 or vs.net), we can use an option (/ZD,/z7,/zi,/zi) to inform the compiler to generate debug information for the static library. The key question is where to save the debug information. When you use the/z7 or/ZD option, the debug information is saved in the. LIB file; When you use the/zi or/ZI option, the debug information is saved in the. PDB file (you can of course use/FD to specify the file name). The impact of debug information on the size of the executable, the impact of debug information on the size of the executable file,Where debugging information is stored, it is also indirectly determined by the format used.     COFF and CodeView format, debug information is saved in the executable file, so the size of the executable file will grow significantly (usually more than one or even larger). In the program database format, debug information is saved separately and has little effect on the size of the executable file.     In this case, the executable needs to save a header to facilitate the debugger to locate the debug information, so it needs to grow by about hundreds of bytes. To avoid the expansion of executable files, we need to change the/OPT:REF option to opt:noref while using/debug. To do this, one additional result is to turn off the size optimization of the linker. If you want to restore size optimization, you need to change back to/opt:ref. DBG files use a gadget--rebase--to export the contents of the CodeView format from the executable file into a dbg file. Rebase is included in Visual Studio. In addition to exporting DBG files, it has some other uses. If you are exporting a DBG file, its command line format is: rebase–b baseaddr–x symboldir [-p] exename option Description-B baseaddr Specifies the base address of the executable file, and if you do not want to change the base address, specify the location used by the current executable Address-X Symboldir to make storage. DBG file directory, using "." Represents the current directory-p If the option is used, the DBG file contains only public functions and variables and FPO information such as: The following command line exports debug information from the DLL to the DBG file in the current directory: Rebase–b 0x60000000–x. The format of the MyDll.dll debugger and debug information is supported by the following formats: Debugger COFF CodeView Program Database (2.0) program database (7.0) Visual Studio.NET -+ + +visual C + + 6.0 + + +-windbg 6.3 + partial support + + WINDBG 6.3 section supports CodeView format, it can only read the following information: public functions and variables FPO information source files and line of code information it can Stepping into the source code, you see the call stack, but cannot observe the value of the variable (so the type information is not supported). Operating system symbol files (symbols) the debug system format exposed by the Windows operating system is as follows: Operating system format WINdows NT 4.0 CodeView (. DBG files) Windows CodeView (. DBG files) and program database (2.0) Windows XP (including SP1 and SP1a) program database (2.0) Windows XP SP2 program Dat  Abase (7.0) Windows 2003 Server Program Database (2.0)

Windows program Debugging Series: Using VC + + to generate debugging information to turn