Another topic that comes up all the time (and is the duty of the build team) is creating and maintaining symbols for various builds. Since this topic does not really fit into any of the chapters in this book, I thought I would include some notes and some of the best practices in this appendix.
A great place to start on debugging and symbols is at http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx.
The best book concerning these areas is written by, arguably, the single best source on debugging and symbols, John Robbins: Debugging Applications for Microsoft .NET and Microsoft Windows.
I will give a brief overview of what symbols are, give an example of what Windows does to build them, and a short pointer on setting up a symbol server that the build team would own.
Symbol files (or symbols) are required to do both kernel and usermode debugging in Windows or Windows applications. Symbols make debugging possible by providing data, such as variable and function names, for a loaded executable file.
The linker (and the compiler [csc.exe] in .NET) in C++ or C produces symbols when a program is built and puts them in a separate file with a .PDB (Program Database) extension. The symbols in a PDB file are called CodeView symbols. The linker creates a full PDB file that contains some private information which, in most cases, should not be shipped externally to customers. The Windows build process strips this private information out of the PDB file and ships the stripped PDB to customers. You can do this by using the /PDBSTRIPPED linker switch. In fact, the stripped PDB file will be generated alongside the full PDB file so that you can use this with your release builds. The following is a brief description of the information contained in full PDBs and stripped PDBs.
Contain all the information you would ever want about an image: global variables, function namesaddresses, frame pointer omission (FPO) data, line numbers (to match up with the source), and local variables.
Required for internal use only.
Stripped PDBs:
Contain the minimum amount of information necessary to get stack traces: function names and addresses, and FPO data. Getting valid stack traces is very important. It provides product support and provides customers a means for obtaining basic information about where bugs are occurring in the source code.
Are shipped on the Customer Support Diagnostics CD and are available to every customer by default in Windows.
Windows 2000 and its service packs are built with the VC 5 compiler and linker. Windows XP is built with the VC 7 compiler and linker. However, because VC 7 did not ship before Windows XP, the 32-bit builds of Windows XP used a VC 7 compiler switch (in this case, /Zvc6) and linker option (in this case, /debugtype:vc6) to create PDB files that have the VC 6 format.
For Windows 2000 and its service packs, the VC 5 linker also left some additional debugging information in the image. The Windows build process strips this data out of the image and saves it in a separate file with a .DBG extension. This considerably reduces the file size, which decreases file load times and thus increases system performance.
The VC 6 and VC 7 linker puts all of the debugging information into the PDB file, thus eliminating the need to create a DBG file.
Windows 2000 binaries each have two symbol files: a .DBG and a .PDB file. Binaries for Windows XP and beyond only have a .PDB file since all of the information is inclusive.
You may want or need to follow the same symbol process that Windows used in order to make sure all of the symbols of your different version applications match.
As John Robbins points out in his book, you should “build all builds, including release builds, with full debugging symbols.” Another important point he makes is that Q/A or test must use debug and release builds for testing. He proposes that the test team alternates between debug and release builds, depending where you are in your shipping cycle. After the release candidate (RC) milestone, he notes, you should be testing release builds exclusively.
The best way to get everyone in your company to use the correct symbols is to centralize all of the symbols using a symbol server or symbol store. It is so valuable that Microsoft keeps a live symbol server for Windows and other products at this site: http://msdl.microsoft.com/download/symbols. You may want to consider doing this for your customers. Again, check this site for details on how to access Microsoft’s symbol server or set one up for yourself: http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx.
This appendix does not even scratch the surface of the symbol/debugging iceberg, but I hope you will see the relevance to the build team and now have the references to help you research the topic further.