C++ tips: Disable "Enable Incremental Linking" linker option to get better symbols
By default, Visual Studio does not generate very friendly symbol names. For example, if you build below code, then run it under windbg:
#include "stdafx.h"
class MyClass
{
public:
MyClass();
void Func1();
};
MyClass::MyClass()
{
printf("in MyClass::MyClass\r\n");
}
void MyClass::Func1()
{
printf("in MyClass::Func1\r\n");
}
int _tmain(int argc, _TCHAR* argv[])
{
MyClass obj1;
obj1.Func1();
return 0;
}
If you check the assembly of wmain, you will see some unfriendly symbol names as highlighted below:
0:000> uf testsymbol!wmain
......
25 012e720e 8d4dfb lea ecx,[ebp-5]
25 012e7211 e8fbe0ffff call testSymbol!ILT+780(??0MyClassQAEXZ) (012e5311) >>>>this is the constructor call
26 012e7216 8d4dfb lea ecx,[ebp-5]
26 012e7219 e801e7ffff call testSymbol!ILT+2330(?Func1MyClassQAEXXZ) (012e591f) >>>>this is obj1.Func1();
......
If you check the assembly in VS directly, VS shows you the friendly name since it has the right info to figure out the symbol names for you:
MyClass obj1;
013C720E lea ecx,[obj1]
013C7211 call MyClass::MyClass (13C5311h)
obj1.Func1();
013C7216 lea ecx,[obj1]
013C7219 call MyClass::Func1 (13C591Fh)
My coworker tells my set the "Enable Incremental Linking" linker option to no can avoid this issue:
I set this option to no, then rebuild the code, this time, I get friendly names in windbg now:
0:000> uf testsymbol!wmain
......
25 010810be 8d4dfb lea ecx,[ebp-5]
25 010810c1 e83affffff call testSymbol!MyClass::MyClass (01081000)
26 010810c6 8d4dfb lea ecx,[ebp-5]
26 010810c9 e882ffffff call testSymbol!MyClass::Func1 (01081050)
27 010810ce 33c0 xor eax,eax
......
Comments
- Anonymous
July 24, 2014
This is not because of "better symbols" but because when incremental linking is enabled, the 'call' addresses to the incremental linking thunk (ILT) which then jumps to the actual function.