VS2010-Incremental Linker File增量连接文件和Program Debuge Dtatbase程序调试信息库文件

最新推荐文章于 2019-11-08 14:52:18 发布

pcliuguangtao

最新推荐文章于 2019-11-08 14:52:18 发布

阅读量5k

点赞数

分类专栏： C/C++ 文章标签： linker file 2010 debugging microsoft dll

本文链接：https://blog.csdn.net/pcliuguangtao/article/details/5920966

版权

本文详细介绍了VS2010中增量链接（.ilk文件）和程序调试数据库（.pdb文件）的原理和作用。增量链接允许在调试版本中快速更新函数，减少对exe的修改，而pdb文件则存储调试信息，包括符号、源文件行号和变量类型。在发布版本中，通常禁用增量链接以减小文件大小。

摘要由CSDN通过智能技术生成

一个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，