本文共 3343 字,大约阅读时间需要 11 分钟。
VS debug下为什么call 函数后,会jmp函数地址?多此一举?
在写的时候,碰到了很奇怪的问题。
initBreak是函数名,start3是指针,它们的值竟然不一样。
开始学习C语言的时候,就知道函数名代表函数地址,可以被赋值给函数指针,方便后面的调用。为什么这里的值会不一样了?
还是使用跑在代码例子,继续用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+0x1b0:000> dd start l4 00416728 00411186 00411023 0041118b 000000000:000> dd start2 l4 00416208 00411186 00411023 0041118b 000000000:000> dd start3 l4 004166240041118b00000000 00000000 000000000:000> dd start4 l4 004168380041118b00000000 00000000 000000000: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 = 0x0041118b0:000> ln start4
(00416838) testC!start4 | (0041693c) testC!pinit Exact matches: testC!start4 = 0x0041118b0: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],altestC!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即可,代价是链接时间的变长,没有两全其美的方法。
转载地址:http://gyfhj.baihongyu.com/