学步园

一个project采用release/debuge来生成，是很有差别的，我试了一下采用debuge并选择“Use MFC shared DLL”产生的exe文件大小为161KB，采用release并选择“Use MFC static DLL”生成的exe大小为1.7MB；需要说明的是采用Use MFC static DLL生成的exe可以在别的机器上（没有安装MFC DLL库的机器）运行，利用shared dll产生的exe由于本身不包含所需的dll文件，所以在有的机器上无法正常运行。

debuge文件夹里面还有两个文件*.ilk和*.pdb;两者分别是incremental linker file和program debuge database.

下面是找到的资料：

http://blog.csdn.net/alleyu/archive/2008/10/27/3160451.aspx

想想如果我们自己要做编译器(compiler)和连接器(linker)，当然希望编译连接运行得越快越好，同时也希望产生的二进制代码也是又快又小，上帝是公平的，鱼与熊掌不可兼得，所以我们自然想到用两种build方式，一种Release，编译慢一些，但是产生的二进制代码紧凑精悍，一种Debug，编译运行快，产生的代码臃肿一点没关系，Debug版本嘛，就是指望程序员在开发的时候反复的build，为了不浪费程序员的时候，要想尽办法让编译连接速度变快。

假如一个程序有连续两个foo和bar函数 (所谓连续，就是他们编译连接之后函数体连续存放)， foo入口位置在0x0400，长度为0x200个字节，那么bar入口就应该在0x0600 = 0x0400+0x0200。程序员在开发的时候总是频繁的修改code然后build，假如程序员在foo里面增加了一些内容，现在foo函数体占0x300个字节了，bar的入口也就只好往后移0x100变成了0x0700，这样就有一个问题，如果foo在程序中被调用了n次，那么linker不得不修改这n个函数调用点，虽然linker不嫌累，但是link时间长了，程序员会觉得不爽。所以MSVC在Debug版的build，不会让各个函数体之间这么紧凑，每个函数体后都有padding（全是汇编代码int 3，作用是引发中断，这样因为古怪原因运行到不该运行的padding部分，会发生异常），有了这些padding，就可以一定程度上缓解上面提到的问题，不过当函数增加内容太多超过padding，还是有问题，怎么办呢？MSVC在Debug build中用上了Incremental Link Table， ILT其实就是一串jmp语句，每个jmp语句对应一个函数，jmp的目的地就是函数的入口点，和没有ILT的区别是，现在对函数的调用不是直接call到函数入口点了，而是call到ILT中对应的位置，而这个位置上什么也不做，直接jmp到函数中去。这样的好处是，当一个函数入口地址改变时，只要修改ILT中对应值就搞定了，用不着修改每一个调用位置（也就是不用重新生成exe文件），用一个冗余的ITL把时间复杂度从O(n)将为O(1)，值得，当然Debug版的二进制文件会稍大稍慢，Release版不会用上ILT（release文件夹里面就没有ilk文件，只有pdb文件）。

编译器CL.EXE的选项/INCREMENTAL

The /INCREMENTAL option controls how the linker handles incremental linking.

By default, the linker runs in incremental mode. To override a default incremental link, specify /INCREMENTAL:NO.

An incrementally linked program is functionally equivalent to a program that is nonincrementally linked. However, because it is prepared for subsequent incremental links, an incrementally linked executable (.exe) file or dynamic-link library (DLL):

• Is larger than a nonincrementally linked program because of padding of code and data. (Padding allows the linker to increase the size of functions and data without recreating the .exe file.)

• May contain jump thunks to handle relocation of functions to new addresses.

  Note

  To ensure that your final release build does not contain padding or thunks, link your program nonincrementally.

To link incrementally regardless of the default, specify /INCREMENTAL. When this option is selected, the linker issues a warning if it cannot link incrementally, and then links the program nonincrementally. Certain options and situations override /INCREMENTAL.

Most programs can be linked incrementally. However, some changes are too great, and some options are incompatible with incremental linking. LINK performs a full link if any of the following options are specified:

• Link Incrementally is not selected (/INCREMENTAL:NO)

• /OPT:REF is selected

• /OPT:ICF is selected

• /ORDER is selected

/INCREMENTAL is implied when /DEBUG is specified.

Additionally, LINK performs a full link if any of the following situations occur:

• The incremental status (.ilk) file is missing. (LINK creates a new .ilk file in preparation for subsequent incremental linking.)

• There is no write permission for the .ilk file. (LINK ignores the .ilk file and links nonincrementally.)

• The .exe or .dll output file is missing.

• The timestamp of the .ilk, .exe, or .dll is changed.

• A LINK option is changed. Most LINK options, when changed between builds, cause a full link.

• An object (.obj) file is added or omitted.

• An object that was compiled with the /Yu /Z7 option is changed.

To set this linker option in the Visual Studio development environment

1. Open the project's Property Pages dialog box. For details, see Setting Visual C++ Project Properties.

2. Click the Linker folder.

3. Click the General property page.

4. Modify the Enable Incremental Linking property.

验证了一下：在你选择debuge模式下，编译选项会自动设置成增量连接；在你选择release模式下，编译选项会禁止增量连接(/INCREMENTAL:NO)。

*************************************************************************************************************************************************************************************

Program Database是目前最新的Debug信息格式。目前为此已经出现了两个版本，一个是用于Visual studio6.0的PDB20，另一个是用于Visual studio.Net(2002 or 2003)的PDB70。然后后者并不会兼容前者，所以visual studio6.0将不能使用最新的PDB70。

下面指出PDB中通常会保存一些什么类型的信息：全局函数和变量；成员函数、成员变量及局部变量；符号对应的源文件中的行号；变量类型信息；FPO信息；编辑后继续运行信息。一般来说对于每一种符号都会有相应的保存属性，符号类型、地址、大小和符号名。

Program Database信息是与文件执行体分离的，通常它会保存在.pdb后缀的文件中。PDB文件的建立是与编译器和链接器紧密相连的。通过设定编译器选项（/ZI, /Z7, /Zi, /Zd）,编译器可以在编译源文件时对应每一个源文件产生一个相应的调试符号文件；然后设定相应的链接器选项（/DEBUGTYPE， /DEBUG， /PDB等）可以将单个的调试符号文件合并成PDB文件。

如果你要利用PDB为你的工作服务，你可以使用最新的Debugging Tools for Window来对PDB文件（当然也可以是EXE和DLL文件）进行对符号信息的操作。

来自维基百科

PDB stands for Program Database, a proprietary file format (developed by Microsoft) for storing debugging information about a program (or, commonly, program modules such as a DLL or EXE). PDB files commonly have a .pdb extension. A PDB file is typically created from source files during compilation. It stores a list of all symbols in a module with their addresses and possibly the name of the file and the line on which the symbol was declared. This symbol information is not stored in the module itself, because it takes up a lot of space.

When a program is debugged, the debugger loads debugging information from the PDB and uses it to locate symbols or relate current execution state of a program source code. Microsoft Visual Studio uses PDB files as its primary file format for debugging information.

Another use of PDBs is in services that collect crash data from users and relate it to the specific parts of the source code that cause (or are involved in) the crash. An example of this is SupportSoft's Talkback.

PDB files are usually stripped of programs' distribution package. They are used by developers during debugging to gain time and insight.

Although the PDB format is undocumented and proprietary, information can be extracted from a PDB-file using the DIA (Debug Interface Access) interfaces, available on Microsoft Windows.