Microsoft® PE Format Support in SourcePoint

Overview

Definition of PE

PE32/PE32+ defines the SP32 Portable Executable File Format. PE is a load time relocatable file format that can contain multiple sections/segments inside of a single file. The Extensible Firmware Interface (EFI) also utilizes the PE format for EFI applications and device drivers. For details of the format, see the Microsoft PE32/COFF File Format Specification.

Definition of PDB

The .PDB extension stands for "program database." It holds the format for storing debugging information that was introduced in Visual C++ version 1.0. One of the most important motivations for the change in format was to allow incremental linking of debug versions of programs, a change first introduced in Visual C++ version 2.0.

While earlier, 16-bit versions of Visual C++ used .PDB files, the debugging information stored in them was appended to the end of the .EXE or .DLL file by the linker. In the versions of Visual C++ mentioned above, both the linker and the integrated debugger were modified to allow .PDB files to be used directly during the debugging process, thereby eliminating substantial amounts of work for the linker and also bypassing the cumbersome CVPACK limit of 64K types.

By default, when you build projects generated by the Visual Workbench, the compiler switch /Fd is used to rename the .PDB file to <project>.PDB. Therefore, you will have only one .PDB file for the entire project.

When you run makefiles that were not generated by the Visual Workbench, and the /Fd is not used with /Zi, you will end up with two .PDB files:

• VCx0.PDB (where "x" refers to the major version of the corresponding Visual C++, either "2" or "4"), which stores all debugging information for the individual .OBJ files. It resides in the directory where the project makefile resides.

• <project>.PDB, which stores all debugging information for the resulting .EXE file. It resides in the \WINDEBUG subdirectory.

Why two files? When the compiler is run, it doesn't know the name of the .EXE file into which the .OBJ files will be linked, so the compiler can't put the information into <project>.PDB. The two files store different information. Each time you compile an .OBJ file, the compiler merges the debugging information into VCX0.PDB. It does not put in symbol information such as function definitions. It only puts in information concerning types. One benefit of this is that when every source file includes common header files such as <windows.h>, all the typedefs from these headers are only stored once, rather than in every .OBJ file.

When you run the linker, it creates <project>.PDB, which holds the debugging information for the project's .EXE file. All debugging information, including function prototypes and everything else, is placed into <project>.PDB, not just the type information found in VCX0.PDB. The two kinds of .PDB files share the same extension because they are architecturally similar; they both allow incremental updates. Nevertheless, they actually store different information.

The new Visual C++ debugger uses the <project>.PDB file created by the linker directly, and embeds the absolute path to the .PDB in the .EXE or .DLL file. If the debugger can't find the .PDB file at that location or if the path is invalid (if, for example, the project was moved to another computer), the debugger looks for it in the current directory.

FAQs

What tool-chains has the SourcePoint PE Loader been validated against?

May 2002 Microsoft platform SDK
      compiler( cl)   version 13.00.9500.7  ( for IA64)
      linker (link)      version 7.00.9500.7

Microsoft Visual Studio.Net  ( Visual C++ Version 7) ( for 32bit)
     compiler( cl)    version 13.00.9466
     linker      (link)  version 7.00.9466

Microsoft Window server 2003 DDK
    compiler( cl)   version 13.10.2240.8  for IA64
    linker       (link) version 7.10.2240.8   for IA64
    compiler(cl) version 13.10.2207  for AMD64
    linker      (link) version 7.10.2207 for AMD64

PE supports several symbol formats. Which format is supported by SourcePoint?

SourcePoint supports Codeview both in .PDB format and “non-PDB” format. SourcePoint does not support COFF symbols within a PE file.

Why are COFF symbols not supported?

COFF symbols were used with early versions of Microsoft® Windows® and with MASM. Although the COFF format has line number information, the latest MS Linker does not generate line number information when COFF is used. COFF symbols in a PE format file would not support the display of source code in the Code window.

Does SourcePoint support C++ with PE format?

Not in the current version of SourcePoint. PE/PDB support in SourcePoint is for C language level support is primarily intended for EFI debugging. However, SourcePoint can load the symbols of a C++ application. Some of the symbols will be readable while others will be in a mangled format. The user can differentiate "classes" from "structures," but the class properties and methods are not directly associated.

Does SourcePoint support debugging 32-bit PE applications?

SourcePoint supports 32-bit (PE32) versions of the PE format.

What linker switch is used to create CodeView/PDB?

     /DEBUG /DEBUGTYPE:CV for PDB

     /DEBUG /DEBUGTYPE:CV /PDB:NONE for CodeView without PDB

     /DEBUG /DEBUGTYPE:COFF for COFF

Does SourcePoint support PE/PDB generated by SEPTYPE option?

No, SourcePoint does not support PDB generated by PDBTYPE:SEPTYPE. When the PDBTYPE:SEPTYPE switch is used, type information is put into separate files other than the PDB file. SourcePoint does not read these files. In Visual C++, the Separate Types button in Category: "Debug" in Link page of Project|Settings must be unchecked to generate symbols compatible with SourcePoint.

Does SourcePoint support .DBG format?

No. SourcePoint does not support the .DBG format.

Does SourcePoint support PE files containing multiple code sections (segments)?

Yes.

Known restrictions of PE/PDB support in SourcePoint

• Separate Typefile. Separate type information file is not supported as described above.

• Demand Loading. For PDB, demand loading is not supported in SourcePoint.

• Module Range. Since PDB does not provide an accurate module range, SourcePoint guesses at the last address of module from last line number of the module. Codeview ( without PDB) provides the exact size of a module, and SourcePoint can have accurate module range.

• SourcePoint does not support PDB formats generated by MS Linker ver 5.xx and older.