SourcePoint AMD Help
Table of Contents
- Using Help
- Contacting ASSET InterTech
- Introduction to SourcePoint
- SourcePoint Environment
- SourcePoint Overview
- SourcePoint Parent Window Introduction
- SourcePoint Icon Toolbar
- File Menu
- File Menu - Project Menu Item
- File Menu - Layout Menu Item
- File Menu - Program Menu Item
- File Menu - Macro Menu Item
- File Menu - Print Menu Items
- File Menu - Update Emulator Flash Menu Item
- File Menu - Program Target Device Menu Item
- File Menu - Other Menu Items
- Edit Menu
- View Menu
- Processor Menu
- Options Menu
- Options Menu - Preferences Menu Item
- Options Menu - Target Configuration Menu Item
- Options Menu - Load Target Configuration File Menu Item
- Options Menu - Save Target Configuration File Menu Item
- Options Menu - Emulator Configuration Menu Item
- Options Menu - Emulator Connection Menu Item
- Options Menu - Emulator Reset Menu Item
- Options Menu - Confidence Tests Menu Item
- Window Menu
- Help Menu
- How To -- SourcePoint Environment
- Add Emulator Connections
- Configure Custom Macro Icons
- Configure Autoloading Macros
- Display Text on the Icon Toolbar
- Edit Icon Groups to Customize Your Toolbars
- Modify a Defined Memory Region
- Refresh SourcePoint Windows
- Save a Program
- Start SourcePoint With Command Line Arguments
- Use the New Project Wizard
- Verify Emulator Network Connections
- SourcePoint Overview
- Breakpoints Window
- Code Window
- Command Window
- Command Window Overview
- Confidence Tests Window
- Descriptors Tables Window
- Devices Window
- Log Window
- Memory Window
- Page Translation Window
- Page Translation Windows Overview
- PCI Devices Window
- PCI Devices Window Overview
- How To - PCI Devices Window
- Registers Window
- Symbols Windows
- Viewpoint Window
- Watch Window
- Technical Notes
- SourcePoint Command Language
- Commands and Control Variables
- bell (beep)
- Character Functions
- cpubreak commands
- dbgbreak commands
- do while
- execution point ($)
- list, nolist
- log, nolog
- Memory Access
- print cycles
- Register Access
- softbreak, softremove, softdisable, softenable
- string [ ] (index into string)
- taskbreak, taskremove, taskdisable, taskenable
Microsoft® PE Format Support in SourcePoint
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.
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)?
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.