PDB文件的介绍

PDB（Program Data Base），意即程序的基本数据，是VS编译链接时生成的文件。DPB文件主要存储了VS调试程序时所需要的基本信息，主要包括源文件名、变量名、函数名、FPO(帧指针)、对应的行号等等。因为存储的是调试信息，所以一般情况下PDB文件是在Debug模式下才会生成。

PDB文件的调用过程

模块(Module)，EXE和DLL都可以称之为模块，因为它们都有自已独立的Stack，所以我们在调试程序时，可以在Call Stack窗口查看到所有调用的Module Name。并且可以右键查看相应模块的ybmol Load Information，即该模块调用的PDB文件路径的过程。

每个模块被载入的时候，其相同名字的PDB文件同时被载入。所以Debug模式下，不仅因为代码没有优化，同时因为要载入PDB文件，所以Debug模式下的程序执行速度非常慢。

每个模块只会生成一个相同名字的PDB文件，并且模块生成的同时，会校验PDB文件生成GUID记录在模块内。这是因为调试时，调试器强制要求每个模块必须和PDB文件保持一致。实验过程中，用之前生成的PDB文件替换当前生成的PDB文件时，Debug窗口会显示No symbols loaded. MSDN也做了相应的说明：The debugger will load only a PDB for a binary that exactly matches the PDB that was created when the binary was built.

PDB文件中记录了源文件路径的相关信息，所以在载入PDB文件的时候，就可以将相关调试信息与源码对应。这样可以可视化的实时查看调试时的函数调用、变量值等相关信息。模块当中记录的PDB文件是绝对路径。所以只要模块在当前电脑上载入，调试器自然地会根据模块当中的路径信息找到相应PDB文件并载入。同样PDB文件中记录的源文件路径也是绝对路径，所以PDB文件只要在当前电脑上载入，调试进入相应模块时，都能够匹配到记录的源文件，然后可视化地查看相应信息。

.pdb文件，是VS生成的用于调试的符号文件（program database），保存着调试的信息。在VS的工程属性，C/C++，调试信息格式，设置/Zi，那么VS就会在构建项目时创建PDB文件。

在这里要区分两种情况：

1、构建静态库时，可以在工程属性 –> C/C++ –> 输出文件 –> 程序数据库名 设置生成的pdb文件名称，如果不指定，默认是生成为VCx0.pdb，这里x是VS版本号，例如用VS2005，就会生成VC80.pdb。这里就会产生一个疑问，编译静态库时默认生成的.pdb文件名字都一样，那引用这个静态库的项目最后能找到正确的.pdb文件吗？答案是肯定的，因为VS会在生成的文件中嵌入 .pdb 文件的路径。

举个例子，在Project/ToolA下，构建了一个静态库ToolA.lib，对应生成一个vc80.pdb，同样在在Project/ToolB下，构建了一个静态库ToolB.lib，对应生成一个vc80.pdb。然后最终的工程Work.exe同时链接了这两个静态库.这时，生成Work.pdb的时候，就会在ToolA.lib中找到它对应的符号文件路径Project/ToolA/vc80.pdb，以及ToolB.lib对应的符号文件路径Project/ToolB/vc80.pdb，合并生成最终工程的Work.pdb。

2、构建可执行文件或动态库，这种情况下，编译器会生成一个.pdb文件，链接器会生成一个.pdb文件，编译器生成的pdb文件可以在在工程属性 –> C/C++ –> 输出文件 –> 程序数据库名 设置，链接器生成的.pdb文件可以在工程属性 –> 链接器 –> 调试 –> 生成调试信息（设置Yes）,生成程序数据库名设置。

这两个pdb文件有什么不一样呢？编译器生成的pdb文件，默认也是用vcx0命名，是编译器在编译过程中，把每个.obj文件对应的符号信息存储在其中的，但不包括函数定义。而链接器生成的.pdb文件，默认使用工程名命名，是链接器在链接工程时，根据编译器生成的vcx0.pdb再进一步加工出来的，具有完整信息的符号文件。就像链接器根据各个.obj文件生成exe或dll一样，编译器生成的.pdb文件是编译-链接过程的中间产物，最后用于调试程序的是链接器生成的ProjectName.pdb.

上面说的是pdb文件生成规则。在使用的时候，调时期会取到文件对应的pdb文件路径，然后去那个路径（绝对路径）下找，如果这个exe或者dll是自己编的，那无论它放在哪里，pdb文件只要不动，调试器都能找到它。如果调试器在那个路径下找不到，就会到exe或者dll的同级目录找。例如这个工程是别人编出来的，连同符号文件一起发过来，我们只要把符号文件与exe或者dll放在同级目录，调试器也能找到它。当然，在调试器中也可以自己指定符号文件路径。

这两天纠结项目中各种静态库，动态库，可执行文件的调试以及对应的符号文件，总算搞清楚pdb文件的生成以及使用规则，在此总结记录一下。

PDB文件的内容

正式开始PDB的内容，PDB不是公开的文件格式，但是Microsoft提供了API来帮助从PDB中获取数据。
 
Native C++ PDB包含了如下的信息：
 * public，private 和static函数地址；
 * 全局变量的名字和地址；
 * 参数和局部变量的名字和在堆栈的偏移量；
 * class，structure 和数据的类型定义；
 * Frame Pointer Omission 数据，用来在x86上的native堆栈的遍历；
 * 源代码文件的名字和行数；
 
.NET PDB只包含了2部分信息:
 * 源代码文件名字和行数；
 * 和局部变量的名字；
 * 所有的其他的数据都已经包含在了.NET Metadata中了；  
 

PDB如何工作

当你加载一个模块到进程的地址空间的时候，debugger用2中信息来找到相应的PDB文件。第一个毫无疑问就是文件的名字，如果加载 zzz.dll,debugger则查找zzz.pdb文件。在文件名字相同的情况下debugger还通过嵌入到PDB和binay的GUID来确保 PDB和binay的真正的匹配。 所以即使没有任何的代码修改，昨天的binay和今天的PDB是不能匹配的。可以使用dempbin.exe来查看binary的GUID。 
 
在VisualStudio中的modules窗口的symbol file列可以查看PDB的load顺序。第一个搜索的路径是binary所在的路径，如果不在binary所在的路径，则查找binary中hardcode记录的build目录，例如obj\debug\*.pdb, 如果以上两个路径都没有找到PDB，则根据symbol server的设置，在本地的symbol server的cache中查找，如果在本地的symbol server的cache中没有对应的PDB，则最后才到远程的symbol server中查找。通过上面的查找顺序我们可以看出为什么public build和private build的PDB查找不会冲突。 
 
对于private build有时我们需要在别人的机器上debug的情况，需要将相应的PDB与binary一起拷贝，对于加入GAC的.NET的binary，需要将PDB文件拷贝到C:\Windows\assembly\GAC_MSIL\Example\1.0.0.0__682bc775ff82796a类似的binary所在的目录。另一个变通的方法是定义环境变量DEVPATH，从而代替使用命令GACUTIL将binary放入GAC中。在定义DEVPATH后，只需要将binary和PDB放到DEVPATH的路径，在DEVPATH下的binary相当于在GAC下。使用DEVPATH，首先需要创建目录且对当前build用户有写权限，然后创建环境变量DEVPATH且值为刚才创建的目录，然后在web.config，app.config或machine.config中开启development模式，启动对DEVPATH的使用 
<configuration> 
   <runtime> 
      <developmentMode developerInstallation="true"/> 
   </runtime> 
</configuration> 

在你打开了development模式后，如果DEVPATH没有定义或路径不存在的话会导致程序启动时异常"Invalid value for registry"。而且如果在machine.config中开启DEVPATH的使用会影响其他的所有的程序，所以要慎重使用machine.config。 
 
最后开发人员需要知道的是源代码信息是如何存储在PDB文件中的。对于public builds，在运行source indexing tool后，版本控制工具将代码存储到你设置的代码cache中。对于private builds，只是存储了PDB文件的全路径，例如在c:\foo下的源文件mycode.cpp，在pdb文件中存储的路径为c:\foo\mycode.cpp。对于private builds可以使用虚拟盘来增加PDB对绝对路径的依赖，例如可以使用subst.exe将源代码路径挂载为V:，在别人的机器上debug的时候也挂载V：。

• pdb