How Purify Uses Relocation, Debug, and Symbol Data (Error Detection)
Purify uses certain module-related data to support instrumentation of native-compiled code at different levels. The amount of detail that you see in Error Views and coverage tabs depends on what data is available when Purify instruments a module. The following table shows the connection between the level of error-checking and coverage-monitoring instrumentation and three data types: relocation data, debug line data, and symbol data.
Data types |
Error checking |
Coverage monitoring |
Relocation data |
Required for precise and minimal instrumentation. If not available, Purify excludes the module from instrumentation. |
Required for line-level and function-level instrumentation. If not available, Purify excludes the module and does not collect coverage data.
|
Debug line data |
Required for Purify to display line numbers and source code in the Error View. |
Required for line-level and function-level instrumentation. If not available, Purify excludes the module and does not collect coverage data.
|
Symbol data |
Required for Purify to identify function names in call stacks. If not available, Purify labels functions ??? |
Required for Purify to identify function names. If not available, Purify labels functions UnnamedFunction@<offset>. |
Notes:
§ In Visual Studio, you can build a release or debug version of a program that contains relocation data by specifying the /fixed:no and /incremental:no linker options. For more information on the recommended settings for Visual Studio .NET, Visual Studio 2005 and Visual Studio 2008, click ., and for Visual Studio 6, click
.
§ For information on how Purify locates debug data, click
§ To make debug data available, link using the debug switches and then place the debug symbol files in the same directory as the module file before you instrument and run the program. If you are building a test case, include a debug switch such as /Zi or /Zd. For example: cl /Zi test.cpp
You can also get debug data for the C runtime library by using the switches /MDd, /MLd, or /MTd, as appropriate.
To provide a .map file, link with the /map option. For example, specifying the following option set compiles Test.cpp as an optimized module, without debug data, but the linker generates a .map file: cl /O2 test.cpp /link /map
§ Purify reinstruments debug data files (.pdb, .map, or .dbg) only when the associated module is reinstrumented.
§ If the program uses the CRT malloc or new APIs to allocate dynamic memory, and the program was built with the statically linked CRT, you should make debug data available when you instrument and run the program with Purify. This ensures that Purify can detect as many problems as possible, and provide the most useful diagnostics.
(C) Copyright IBM Corporation 1992, 2010.