cleak / virtualfunctionperf Goto Github PK

when you see in the disassembly, you would find vc calls jump to the jmp tables why the calls can be hooked.
a virtual method call in the vc disassemby code, it first jump to the jmp table and then access the virtual table.
a non-virtual method call at first jump to the jmp table and then jmp to actual text code.
when call the a virtual method directly like you do, the disassembly code skip the first jump and directly access the virtual table pointer. thus you think it beats the non-virtual method calls.

and gcc implements virtual table pointer very different from vc, it may generate branches. calling virtual method like you supposed may beats nonvirt method more much. but that is not the fact.

Looking at system call there is a PAUSE command invoke so I was afraid this was not going to compile with gcc.
Fixing is ease: gcc supports attribute((noinline)) void IncrementDirect() instead of declspec

Issue with vtable trick was not that easy to fix:

(gdb) p *((void **) obj)
$26 = (void *) 0x403070 <vtable for IncrementerVirtual+16>

Using your syntax:

(gdb) p ((((void ***) obj))+0)
$161 = (void *) 0x401c60 IncrementerVirtual::~IncrementerVirtual()
(gdb) p ((((void ***) obj))+1)
$162 = (void *) 0x401c88 IncrementerVirtual::~IncrementerVirtual()
(gdb) p ((((void ***) obj))+2)
$163 = (void *) 0x401cb4 IncrementerVirtual::Increment()

In your code offset +1 points to destructor, so I had to use offset +2 in your code.

With my syntax using array index:
VoidMemberFn* updateFn = (VoidMemberFn*)(&(GetVTable(dynamic_cast<IncrementerBase*> (objs[0])))[2]);

Very nice program by the way