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 (1)

  1. Macaque says:

    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.

Skip to main content