原贴最初发布在QQ空间里，见http://user.qzone.qq.com/31731705/blog/1302859584，那里格式较好。

在写跑在main之前的时候，碰到了很奇怪的问题。

int initBreak()
{
DebugBreak();
return 0;
}

typedef int (*pInit)();

pInit start3 = initBreak;

initBreak是函数名，start3 是指针，它们的值竟然不一样。

开始学习C语言的时候，就知道函数名代表函数地址，可以被赋值给函数指针，方便后面的调用。为什么这里的值会不一样了？

还是使用 跑在main之前 (2) 代码例子，继续用windbg分析。

0:000> g
Fri Apr 15 17:03:10.492 2011 (UTC + 8:00): Breakpoint 0 hit
eax=00000000 ebx=7ffdf000 ecx=0041956c edx=00130000 esi=00000000 edi=00000000
eip=0f9186a6 esp=0012ff30 ebp=0012ff34 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
MSVCR100D!_initterm_e+0x6:
0f9186a6 c745fc00000000  mov     dword ptr [ebp-4],0  ss:0023:0012ff30={testC!__native_startup_lock (0041956c)}

0:000> kPL
ChildEBP RetAddr  
0012ff34 0041272b MSVCR100D!_initterm_e(
   <function> ** pfbegin = 0x0041641c, 
   <function> ** pfend = 0x00416a40)+0x6
0012ff80 0041263f testC!__tmainCRTStartup(void)+0xdb
0012ff88 77773c45 testC!mainCRTStartup(void)+0xf
0012ff94 77ce37f5 kernel32!BaseThreadInitThunk+0xe
0012ffd4 77ce37c8 ntdll!__RtlUserThreadStart+0x70
0012ffec 00000000 ntdll!_RtlUserThreadStart+0x1b

0:000> dd start l4
00416728  00411186 00411023 0041118b 00000000
0:000> dd start2 l4
00416208  00411186 00411023 0041118b 00000000
0:000> dd start3 l4
00416624  0041118b 00000000 00000000 00000000
0:000> dd start4 l4
00416838  0041118b 00000000 00000000 00000000

0:000> ln 41118b
(0041118b)   testC!ILT+390(_initBreak)   |  (00411190)   testC!ILT+395(__controlfp_s)
Exact matches:

0:000> ln start3
(00416624)   testC!start3   |  (00416728)   testC!start
Exact matches:
    testC!start3 = 0x0041118b

0:000> ln start4
(00416838)   testC!start4   |  (0041693c)   testC!pinit
Exact matches:
    testC!start4 = 0x0041118b
0:000> ln initBreak
d:\project\mine\vs.net\testc\testc\testc.c(47)
(004120f0)   testC!initBreak   |  (00412150)   testC!main
Exact matches:
    testC!initBreak (void)

能够看到，start3和start4均为0x0041118b，而函数initBreak则是004120f0，它们的值并不一样，这是为什么呢？

再前进一点点就有答案了，

0:000> u 41118b -8
testC!ILT+380(__RTC_Initialize)+0x2:
00411183 250000e985      and     eax,85E90000h
00411188 0e              push    cs
00411189 0000            add     byte ptr [eax],al
testC!ILT+390(_initBreak):
0041118b e9600f0000      jmp     testC!initBreak (004120f0)
testC!ILT+395(__controlfp_s):
00411190 e987300000      jmp     testC!controlfp_s (0041421c)
testC!ILT+400(__StackOverflow):
00411195 e9d6040000      jmp     testC!_StackOverflow (00411670)
testC!ILT+405(_GetSystemTimeAsFileTime:
0041119a e90d310000      jmp     testC!GetSystemTimeAsFileTime (004142ac)
testC!ILT+410(_f1):
0041119f e96c0d0000      jmp     testC!f1 (00411f10)

真相如此简单，就是一条5个字节的JMP指令。

另一个问题随之而来，编译器为何如此做呢，不是降低效率，多此一举嘛。Google了一下，答案在此：

什么是Incremental Link Table呢？

假如一个程序有连续两个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中对应值就搞定了，用不着修改每一个调用位置，用一个冗余的ITL把时间复杂度从O(n)将为O(1)，值得，当然Debug版的二进制文件会稍大稍慢，Release版不会用上ILT。

所以，想得到正确的结果，disable incremental linking即可，代价是链接时间的变长，没有两全其美的方法