Virtual function and multiple inheritance

Hello everyone,


In the following multiple inheritance sample code, I have tested in class Derived, there are two __vfptr, pointing to the virtual function table for Foo and Goo repectively -- i.e. 8 bytes, 2 pointer on 32-bit machine.

My questions,

1. Why two __vfptr is needed? Why not just one?
2. class Derived has its own virtual method func2, why it does not have its own virtual function table pointer?

Code:

---

class Foo {
public:
        virtual int func() {return 1;};
};

class Goo {
public:
        virtual int func() {return 2;};
};

class Derived: Foo, Goo {
public:
        virtual int func2() {return 3;};
        int increase() {return -1;};
        int decrease() {return -2;};
};

int main()
{
        Derived d;
        int size;

        size = sizeof (d); // size is 8, two __vfptr?

        return 0;
}

---

thanks in advance,
George

Foo and Goo are unrelated classes with virtual functions. Thus, they both need a vptr.

When combining them to be part of Derived, they can't change layout. It would break code. Thus, the combined Derived object has both vptrs.

The Derived object already has two vptrs to choose from. Why would it add yet another?

Thanks CornedBee,


I agree with your theory, but it does not cover one of my confusions, which is, where is class Derived's own __vfptr (points to its own virtual methods)? From debugging, I can not find it out by adding a new method in Derived which is not in Foo and Goo. Like, we add a new virtual method called func_derived.

Code:

---

virtual int func_derived() {return 4;}

---

regards,
George

Quote:

---

Originally Posted by CornedBee

Foo and Goo are unrelated classes with virtual functions. Thus, they both need a vptr.

When combining them to be part of Derived, they can't change layout. It would break code. Thus, the combined Derived object has both vptrs.

The Derived object already has two vptrs to choose from. Why would it add yet another?

---

I repeat:

Quote:

---

The Derived object already has two vptrs to choose from. Why would it add yet another?

---

See, the way virtual tables work, there is one for every class. Derived doesn't need another vptr - it simply lets its base class vptrs point to its own table.

But here is an interesting question: what if the class has two base classes? Which vptr will it use in this case? I'll admit, I've never studied the vptr table.

That's one of the details in the vptr implementation that may very well differ between compilers.

But typically, I'd say it uses that of the first base class.

Hi CornedBee,


I have posted my code and screen snapshot, you can see in Derived class there are two vfptr pointing two different virtual function table.

See the code and attachment, thanks.

Any ideas?

Code:

---

class Foo {
public:
        virtual int func_foo() {return 1;};
};

class Goo {
public:
        virtual int func_goo() = 0;
};

class Goo2: public Goo {
public:
        virtual int func_goo() {return 2;};
};

class Goo3: public Goo2 {
public:
        virtual int func_goo() {return 2;};
};

class Derived: Foo, Goo {
public:
        virtual int func_foo() {return 3;};
        virtual int func_goo() {return 2;};
        virtual int func_derived() {return 4;}
        int increase() {return -1;};
        int decrease() {return -2;};
};

int main()
{
        Derived d;
        Goo2 g2;
        Goo3 g3;
        int size;

        size = sizeof (d); // size is 8, two __vfptr?
        size = sizeof (g2);
        size = sizeof (g3);

        return 0;
}

---

Quote:

---

Originally Posted by CornedBee

I repeat:


See, the way virtual tables work, there is one for every class. Derived doesn't need another vptr - it simply lets its base class vptrs point to its own table.

---

regards,
George

Hi Elysia,


You can find detailed information in my post #7 when there are two vfptr in one class. I provide code and screen snapshots. It is appreciated if you could add some ideas. :-)

Quote:

---

Originally Posted by Elysia

But here is an interesting question: what if the class has two base classes? Which vptr will it use in this case? I'll admit, I've never studied the vptr table.

---

regards,
George

CornedBee already told you: Derived inherits the vtable pointers from its base classes!
The debug window shows it as well. Those pointers are part of the Foo and Goo base classes.
What more do you need to know?

Derived::vftable for Goo
Derived::vftable for Foo

How much clearer can the debugger be?



... not that it matters. That stuff is interesting if you want to implement a C++ compiler yourself.

Thanks Elysia,


Why virtual function func_derived of class Derived is not in virtual table of class Derived? In virtual function theory, all virtual tables should be in vtable.

Quote:

---

Originally Posted by Elysia

CornedBee already told you: Derived inherits the vtable pointers from its base classes!
The debug window shows it as well. Those pointers are part of the Foo and Goo base classes.
What more do you need to know?

---

regards,
George

Hi CornedBee,


This is what you mentioned before.

"Derived doesn't need another vptr - it simply lets its base class vptrs point to its own table."

But if you debug my simlpe program, Derived class's own virtual function func_derived is not in vtable. Why?

Quote:

---

Originally Posted by CornedBee

Derived::vftable for Goo
Derived::vftable for Foo

How much clearer can the debugger be?



... not that it matters. That stuff is interesting if you want to implement a C++ compiler yourself.

---

regards,
George

Quote:

---

Originally Posted by George2

Thanks Elysia,

Why virtual function func_derived of class Derived is not in virtual table of class Derived? In virtual function theory, all virtual tables should be in vtable.

regards,
George

---

Take a look into the vptr of the base classes and see if you can find it there.

Thanks Elysia,


I can not find virtual method in vtable func_derived and it is missed in vtable of class Derived. Can you find it or meet with similar issues before -- not all virtual methods are in vtable?

Quote:

---

Originally Posted by Elysia

Take a look into the vptr of the base classes and see if you can find it there.

---

regards,
George

I have no idea how it stores the functions the vtables (in case of Derived). They certainly don't show up in the debugger, but they certainly work, so they must be in a vtable. In fact, the assembly shows this.

Thanks Elysia,


1.

What did your assembly shows to prove function func_derived is in vtable?

Quote:

---

Originally Posted by Elysia

I have no idea how it stores the functions the vtables (in case of Derived). They certainly don't show up in the debugger, but they certainly work, so they must be in a vtable. In fact, the assembly shows this.

---

Here is my more simplified case to show virtual function is missing in vtable. In class Goo, function myFunc is missing in vtable, but in class Zoo, it is ok to contain virtual function zoo_func.

2.

Code:

---

#include <iostream>

using namespace std;

class Foo {

        virtual int func1() = 0;
        virtual int func2() = 0;
        virtual int func3() {return 0;}
};

class Goo: Foo {
public:
        virtual int func1() {return 0;}
        virtual int func2() {return 0;}
        virtual int myFunc() {return 1;}
};

class Zoo {

public:

        virtual int zoo_func() {return 0;}
};

int main()
{
        Goo g;
        Zoo z;
        return 0;
}

---

regards,
George

I say it's a limitation of the debugger.

Thanks CornedBee,


So you mean in vtable, myFunc is there, but debugger can not display it? If yes, how could we make conclusion that in vtable, myFunc exists?

Quote:

---

Originally Posted by CornedBee

I say it's a limitation of the debugger.

---

regards,
George

Yes, exactly. You can make this conclusion from the simple fact that calling the function works.

If you can read assembly, it is undeniable proof:

Code:

---

        pD->foo();
00415020  lea        ecx,[ebp-24h]
00415023  call        CMemoryManagerBase<D>::operator-> (4132B7h)
00415028  mov        dword ptr [ebp-140h],eax
0041502E  mov        eax,dword ptr [ebp-140h]
00415034  mov        edx,dword ptr [eax]
00415036  mov        esi,esp
00415038  mov        ecx,dword ptr [ebp-140h]
0041503E  mov        eax,dword ptr [edx]
00415040  call        eax 
00415042  cmp        esi,esp
00415044  call        @ILT+1650(__RTC_CheckEsp) (413677h)
        pC->foo();
00415049  lea        ecx,[ebp-40h]
0041504C  call        CMemoryManagerBase<C>::operator-> (4138C0h)
00415051  mov        dword ptr [ebp-140h],eax
00415057  mov        eax,dword ptr [ebp-140h]
0041505D  mov        edx,dword ptr [eax]
0041505F  mov        esi,esp
00415061  mov        ecx,dword ptr [ebp-140h]
00415067  mov        eax,dword ptr [edx]
00415069  call        eax 
0041506B  cmp        esi,esp
0041506D  call        @ILT+1650(__RTC_CheckEsp) (413677h)
        pB->foo();
00415072  lea        ecx,[ebp-5Ch]
00415075  call        CMemoryManagerBase<B>::operator-> (4132EEh)
0041507A  mov        dword ptr [ebp-140h],eax
00415080  mov        eax,dword ptr [ebp-140h]
00415086  mov        edx,dword ptr [eax]
00415088  mov        esi,esp
0041508A  mov        ecx,dword ptr [ebp-140h]
00415090  mov        eax,dword ptr [edx]
00415092  call        eax 
00415094  cmp        esi,esp
00415096  call        @ILT+1650(__RTC_CheckEsp) (413677h)
        pA->foo();
0041509B  lea        ecx,[ebp-78h]
0041509E  call        CMemoryManagerBase<A>::operator-> (413852h)
004150A3  mov        dword ptr [ebp-140h],eax
004150A9  mov        eax,dword ptr [ebp-140h]
004150AF  mov        edx,dword ptr [eax]
004150B1  mov        esi,esp
004150B3  mov        ecx,dword ptr [ebp-140h]
004150B9  mov        eax,dword ptr [edx]
004150BB  call        eax 
004150BD  cmp        esi,esp
004150BF  call        @ILT+1650(__RTC_CheckEsp) (413677h)

---

Code:

---

        ppnew<D> pD;
        ppnew<C> pC;
        ppnew<B> pB;
        ppnew<A> pA;
        pD->foo();
        pC->foo();
        pB->foo();
        pA->foo();

---

Thanks CornedBee,


"Yes, exactly" -- what is your context? You mean in vtable, myFunc is there, but debugger can not display it? If yes, how could we make conclusion that in vtable, myFunc exists?

Quote:

---

Originally Posted by CornedBee

Yes, exactly. You can make this conclusion from the simple fact that calling the function works.

---

regards,
George

Hi Elysia,


We are talking about virtual function in this topic. Which of your function is virtual? And how to find from assembly whether a virtual function is in vtable?

Quote:

---

Originally Posted by Elysia

If you can read assembly, it is undeniable proof:
[code] pD->foo();
00415020 lea ecx,[ebp-24h]
00415023 call CMemoryManagerBase<D>::operator-> (4132B7h)
00415028 mov dword ptr [ebp-140h],eax
0041502E mov eax,dword ptr [ebp-140h]
00415034 mov edx,dword ptr [eax]
00415036 mov esi,esp
00415038 mov ecx,dword ptr [ebp-140h]
0041503E mov eax,dword ptr [edx]
00415040 call eax
00415042 cmp esi,esp
00415044 call @ILT+1650(__RTC_CheckEsp) (413677h)

---

regards,
George

Code:

---

class A
{
public:
        virtual void foo() { }
};

class B
{
public:
        virtual void foo() { }
};

class C: public A, public B
{
public:
        virtual void foo() { }
};

class D: public C
{
public:
        virtual void foo() { }
};

---

Quote:

---

Originally Posted by George2

Thanks CornedBee,

"Yes, exactly" -- what is your context? You mean in vtable, myFunc is there, but debugger can not display it? If yes, how could we make conclusion that in vtable, myFunc exists?

regards,
George

---

CornedBee means that the vtable exists and the functions are part of the vtable but the debugger can't display it. Debugger limitation.
You can in fact know that it exists in a vtable because it works or by looking at the assembly.
It doesn't take the address of the function and call it. It actually takes the first 4 bytes and dereferences it to call the appropriate function - undeniable proof that the vtable exists.

http://msdn.microsoft.com/archive/de...angrayhood.asp

Old article, but still relevant for VC++.

gg

If a class declares a virtual function and you have an instance of that class why would it have to have an entry for that function in the vtable ? There is not much to look up in a table with just one entry so it might just be optimized away.
Guess that is what you see in your examples. Objects of a class that declare virtual members don't have entries of their ( not yet overridden ) virtual functions in the v-table.
That is just a guess.
Kurt

But your theory seems wrong. This behavior was seen in debug builds, so the compiler couldn't have optimized it away. Yet. In release, it might just do that.
In my own tests, I created 4 classes with the same function, all virtual, so that would force the compiler to make a vtable. Yet, only the functions in A and B are shown in the vtable.
But the assembly shows that the functions do exist in the vtable since it calls a virtual function and, indeed, it calls the right function.

Unless you're writing a compiler you don't need to know how it works, and if you do write a compiler, it'll quickly become blatently obvious why other compilers do things a certain way.

You shouldn't really be using sizeof on a class that has virtual functions. I'm struggling to find any legitimate reason for needing to know the size of a class with virtual functions.

Separating allocation and construction? What do you think std::allocator does?

Thanks Elysia,


Which exact statements in the assembly language do you mean? Could you quote please?

"It actually takes the first 4 bytes and dereferences it to call the appropriate function"

And it is appreciated if you could post you code, and it is good if we could discuss based on the common code base. :-)

Quote:

---

Originally Posted by Elysia

CornedBee means that the vtable exists and the functions are part of the vtable but the debugger can't display it. Debugger limitation.
You can in fact know that it exists in a vtable because it works or by looking at the assembly.
It doesn't take the address of the function and call it. It actually takes the first 4 bytes and dereferences it to call the appropriate function - undeniable proof that the vtable exists.

---

regards,
George

No Zuk, you are wrong. :-)


In my sample, class Zoo has only one method called zoo_func, it is virtual and it is in vtable.

Quote:

---

Originally Posted by ZuK

If a class declares a virtual function and you have an instance of that class why would it have to have an entry for that function in the vtable ? There is not much to
look up in a table with just one entry so it might just be optimized away.
Guess that is what you see in your examples. Objects of a class that declare virtual members don't have entries of their ( not yet overridden ) virtual functions in the v-table.
That is just a guess.
Kurt

---

Hi CornedBee,

Quote:

---

Originally Posted by CornedBee

Separating allocation and construction? What do you think std::allocator does?

---

I am not sure what do you mean. Does your above reply relates to my question?


regards,
George

Quote:

---

Originally Posted by George2

Which exact statements in the assembly language do you mean? Could you quote please?
"It actually takes the first 4 bytes and dereferences it to call the appropriate function"

---

0041502E mov eax,dword ptr [ebp-140h]
00415034 mov edx,dword ptr [eax]
00415036 mov esi,esp
00415038 mov ecx,dword ptr [ebp-140h]
0041503E mov eax,dword ptr [edx]
00415040 call eax

Let's take a look at this assembly. At the beginning of the assembly, the pointer itself is stored within eax. The pointer to the class, the object.
So the next dereferences that pointer and stores it in edx. So it dereferences and stores a 4-byte value in edx. What's the first 4 bytes in a class? The vtable!
The next line is irrelevant.
But the next tells me that the compiler stores the class pointer in ecx, which is basically the "this" register. The register where the "this" pointer is stored.
Moving on, we see that the code dereferences edx, which previously held the value of the dereferenced class pointer, the vtable pointer. And then it calls this address, entering the virtual function.
So that tells me the class looks something like:

Code:

---

class D
{
        VTablePtr* ptr;
        // ...
};

---

And I have a pointer to the class object, pD. So the code is essentially, (*pD->ptr)();

Quote:

---

And it is appreciated if you could post you code, and it is good if we could discuss based on the common code base. :-)

---

I already did. Look up and see the code I used both in C++ and assembly plus the class definition.

Quote:

---

I am not sure what do you mean. Does your above reply relates to my question?

---

No, to iMalc's comment. When I don't quote a question, you can assume that it relates to the post directly above. Actually, you can assume that for most posters, because that' standard protocol. As is top-quoting only the relevant parts of the thing you reply to.

(And when someone posts while I'm typing, I have to edit the post to insert the quote.)

Hi Elysia,


Why I do not have similar assembly code generated? Here is my source codes and generated assembly code, looks like there is no such indirection through vtable?

Code:

---

class Foo {
public:
        virtual int foo() {return 1;}
        int goo() {return 2;}
};

int main()
{
        Foo f;
        f.foo();
        f.goo();

        return 0;
}

---

Code:

---

int main()
{
00941410  push        ebp 
00941411  mov        ebp,esp
00941413  sub        esp,0CCh
00941419  push        ebx 
0094141A  push        esi 
0094141B  push        edi 
0094141C  lea        edi,[ebp-0CCh]
00941422  mov        ecx,33h
00941427  mov        eax,0CCCCCCCCh
0094142C  rep stos    dword ptr es:[edi]
        Foo f;
0094142E  lea        ecx,[f]
00941431  call        Foo::Foo (9410DCh)
        f.foo();
00941436  lea        ecx,[f]
00941439  call        Foo::foo (941055h)
        f.goo();
0094143E  lea        ecx,[f]
00941441  call        Foo::goo (941109h)

---

regards,
George

Quote:

---

Originally Posted by Elysia

0041502E mov eax,dword ptr [ebp-140h]
00415034 mov edx,dword ptr [eax]
00415036 mov esi,esp
00415038 mov ecx,dword ptr [ebp-140h]
0041503E mov eax,dword ptr [edx]
00415040 call eax

Let's take a look at this assembly. At the beginning of the assembly, the pointer itself is stored within eax. The pointer to the class, the object.
So the next dereferences that pointer and stores it in edx. So it dereferences and stores a 4-byte value in edx. What's the first 4 bytes in a class? The vtable!
The next line is irrelevant.
But the next tells me that the compiler stores the class pointer in ecx, which is basically the "this" register. The register where the "this" pointer is stored.
Moving on, we see that the code dereferences edx, which previously held the value of the dereferenced class pointer, the vtable pointer. And then it calls this address, entering the virtual function.
So that tells me the class looks something like:

Code:

---

class D
{
        VTablePtr* ptr;
        // ...
};

---

And I have a pointer to the class object, pD. So the code is essentially, (*pD->ptr)();


I already did. Look up and see the code I used both in C++ and assembly plus the class definition.

---

You must call the function through a pointer. That's the whole ordeal. If you have a local object of type D, then it cannot be type C or Bo or anything else so the compiler knows it can call foo directly.
However, if you have a pointer, then the pointer can be of the base class's type, yet point to a derived type, thus paving way for polymorphism and the vtable.

Thanks Elysia,


I have tested your reply and you are correct. I have got similar result as yours. I have studied your previous statement about the generated assembly again. Looks great!

Just two more comments,

1.

The address of vtable and the address of this pointer are the same, right?

2.

How do you know ptr [ebp-140h] contains the address to current pointer?

--------------------
0041502E mov eax,dword ptr [ebp-140h]
00415034 mov edx,dword ptr [eax]
00415036 mov esi,esp
00415038 mov ecx,dword ptr [ebp-140h]
0041503E mov eax,dword ptr [edx]
00415040 call eax

Let's take a look at this assembly. At the beginning of the assembly, the pointer itself is stored within eax. The pointer to the class, the object.
So the next dereferences that pointer and stores it in edx. So it dereferences and stores a 4-byte value in edx. What's the first 4 bytes in a class? The vtable!
The next line is irrelevant.
But the next tells me that the compiler stores the class pointer in ecx, which is basically the "this" register. The register where the "this" pointer is stored.
Moving on, we see that the code dereferences edx, which previously held the value of the dereferenced class pointer, the vtable pointer. And then it calls this address, entering the virtual function.
--------------------

Quote:

---

Originally Posted by Elysia

You must call the function through a pointer. That's the whole ordeal. If you have a local object of type D, then it cannot be type C or Bo or anything else so the compiler knows it can call foo directly.
However, if you have a pointer, then the pointer can be of the base class's type, yet point to a derived type, thus paving way for polymorphism and the vtable.

---

regards,
George

1. Yes, the vtable is the first item inside the object [although there are other ways to store the vtable, this form makes it easy to follow and it stays constant for different derived classes [if you put the vtable at the end of the structure, it would move based on the number of elements within the struct, for example].

2. From the code-snippet quoted, we can't KNOW what it does. But we can GUESS that EBP-140 is the address of the object. The "this" pointer is commonly stored in a register to avoid stacking overhead [storing the pointer on the stack will be one store, and then a load almost immediately when the call is made - as accessing the "this" pointer in the function called is usually one of the first things actually done in the called function]. MS appears to choose ECX.

The only way to KNOW what's going on is to understand the entire function from start to finish.

--
Mats

Thanks Mats,


I have made some further experiement about the generated assembly code for non-virtual function.

I am confused why there is instruction like,

00BC14EA mov ecx,dword ptr [pf]
00BC14F2 mov ecx,dword ptr [pf]
00BC14FA mov ecx,dword ptr [pb]

I think we can get the address of non-virtual address function directly, and I can not find the usage of register ecx in the code below. Any ideas?

Code:

---

int main()
{
00BC14C0  push        ebp 
00BC14C1  mov        ebp,esp
00BC14C3  sub        esp,0E4h
00BC14C9  push        ebx 
00BC14CA  push        esi 
00BC14CB  push        edi 
00BC14CC  lea        edi,[ebp-0E4h]
00BC14D2  mov        ecx,39h
00BC14D7  mov        eax,0CCCCCCCCh
00BC14DC  rep stos    dword ptr es:[edi]
        Foo f;
        Base* pb = &f;
00BC14DE  lea        eax,[f]
00BC14E1  mov        dword ptr [pb],eax
        Foo* pf = &f;
00BC14E4  lea        eax,[f]
00BC14E7  mov        dword ptr [pf],eax
        pf->foo();
00BC14EA  mov        ecx,dword ptr [pf]
00BC14ED  call        Foo::foo (0BC1064h)
        pf->goo();
00BC14F2  mov        ecx,dword ptr [pf]
00BC14F5  call        Foo::goo (0BC100Ah)
        pb->foo();
00BC14FA  mov        ecx,dword ptr [pb]
00BC14FD  call        Base::foo (0BC103Ch)
        return 0;
00BC1502  xor        eax,eax

---

Code:

---

#include <iostream>

using namespace std;

class Base {
public:
        void foo() {cout << "-1" << endl;}
};

class Foo: public Base {
public:
        void foo() {cout << "1" << endl;}
        void goo() {cout << "2" << endl;}
};

int main()
{
        Foo f;
        Base* pb = &f;
        Foo* pf = &f;
        pf->foo();
        pf->goo();
        pb->foo();
        return 0;
}

---

Quote:

---

Originally Posted by matsp

1. Yes, the vtable is the first item inside the object [although there are other ways to store the vtable, this form makes it easy to follow and it stays constant for different derived classes [if you put the vtable at the end of the structure, it would move based on the number of elements within the struct, for example].

2. From the code-snippet quoted, we can't KNOW what it does. But we can GUESS that EBP-140 is the address of the object. The "this" pointer is commonly stored in a register to avoid stacking overhead [storing the pointer on the stack will be one store, and then a load almost immediately when the call is made - as accessing the "this" pointer in the function called is usually one of the first things actually done in the called function]. MS appears to choose ECX.

The only way to KNOW what's going on is to understand the entire function from start to finish.

--
Mats

---

regards,
George

Some clarifying comments in red below.

Code:

---

int main()
{
00BC14C0  push        ebp 
00BC14C1  mov        ebp,esp
00BC14C3  sub        esp,0E4h
00BC14C9  push        ebx 
00BC14CA  push        esi 
00BC14CB  push        edi 
00BC14CC  lea        edi,[ebp-0E4h]
00BC14D2  mov        ecx,39h
00BC14D7  mov        eax,0CCCCCCCCh
00BC14DC  rep stos    dword ptr es:[edi]
        Foo f;
        Base* pb = &f;
00BC14DE  lea        eax,[f]
00BC14E1  mov        dword ptr [pb],eax    pb = &f
        Foo* pf = &f;
00BC14E4  lea        eax,[f]
00BC14E7  mov        dword ptr [pf],eax    pf = &f
        pf->foo();
00BC14EA  mov        ecx,dword ptr [pf]      this = pf
00BC14ED  call        Foo::foo (0BC1064h)
        pf->goo();
00BC14F2  mov        ecx,dword ptr [pf]    this = pf
00BC14F5  call        Foo::goo (0BC100Ah)
        pb->foo();
00BC14FA  mov        ecx,dword ptr [pb]  this = pb
00BC14FD  call        Base::foo (0BC103Ch)
        return 0;
00BC1502  xor        eax,eax

---

Clearly the code is non-optimized debug build, as it's filling the stack with 0xCC, and it's doing two lea eax, [f] with one instruction that doesn't destroy eax in between.

--
Mats

Thanks Mats,


So ecx is used to contain this pointer?

Quote:

---

Originally Posted by matsp

Some clarifying comments in red below.

Code:

---

int main()
{
00BC14C0  push        ebp 
00BC14C1  mov        ebp,esp
00BC14C3  sub        esp,0E4h
00BC14C9  push        ebx 
00BC14CA  push        esi 
00BC14CB  push        edi 
00BC14CC  lea        edi,[ebp-0E4h]
00BC14D2  mov        ecx,39h
00BC14D7  mov        eax,0CCCCCCCCh
00BC14DC  rep stos    dword ptr es:[edi]
        Foo f;
        Base* pb = &f;
00BC14DE  lea        eax,[f]
00BC14E1  mov        dword ptr [pb],eax    pb = &f
        Foo* pf = &f;
00BC14E4  lea        eax,[f]
00BC14E7  mov        dword ptr [pf],eax    pf = &f
        pf->foo();
00BC14EA  mov        ecx,dword ptr [pf]      this = pf
00BC14ED  call        Foo::foo (0BC1064h)
        pf->goo();
00BC14F2  mov        ecx,dword ptr [pf]    this = pf
00BC14F5  call        Foo::goo (0BC100Ah)
        pb->foo();
00BC14FA  mov        ecx,dword ptr [pb]  this = pb
00BC14FD  call        Base::foo (0BC103Ch)
        return 0;
00BC1502  xor        eax,eax

---

Clearly the code is non-optimized debug build, as it's filling the stack with 0xCC, and it's doing two lea eax, [f] with one instruction that doesn't destroy eax in between.

--
Mats

---

regards,
George

In MS's calling convention, yes.

And don't quote huge posts to answer with a one-liner.

Thanks CornedBee,


Good to know MS always use ecx to hold this pointer.

> And don't quote huge posts to answer with a one-liner.

I will take into consideration in the future. :-)

Quote:

---

Originally Posted by CornedBee

In MS's calling convention, yes.

And don't quote huge posts to answer with a one-liner.

---

regards,
George

Quote:

---

Originally Posted by George2

Good to know MS always use ecx to hold this pointer.

---

No, this is not guaranteed. I have seen assembly code when the this pointer is pushed onto the stack. Don't rely on assembly for these things.

And when I see mov eax, [ebp-140h] I see that it is the first instruction of the line of code and I since I trust the compiler, I know that's the pointer it's putting into eax. If you're skeptical, you could always execute that first assembly instruction and compare the value of eax to the address of the pointer. They should match.

Quote:

---

Originally Posted by Elysia

No, this is not guaranteed. I have seen assembly code when the this pointer is pushed onto the stack. Don't rely on assembly for these things.

---

Only when the function is varargs, at least in the .Net version (7.0) of Visual C++.

Look up "thiscall" in the help section in your VS.

--
Mats

Thanks Elysia and Mats,


Do you know whether Microsoft provides online free manual for the assembly language guide with Visual Studio (i.e. how Visual Studio compiler's assembly language looks like, e.g. which register is used to hold this pointer or something, other than a general assembly language guide)?

Quote:

---

Originally Posted by matsp

Only when the function is varargs, at least in the .Net version (7.0) of Visual C++.

Look up "thiscall" in the help section in your VS.

--
Mats

---

regards,
George

The probably have an ABI guide somewhere, but they'd be pretty stupid to document anything beyond that.

Quote:

---

Originally Posted by George2

Thanks Elysia and Mats,


Do you know whether Microsoft provides online free manual for the assembly language guide with Visual Studio (i.e. how Visual Studio compiler's assembly language looks like, e.g. which register is used to hold this pointer or something, other than a general assembly language guide)?


regards,
George

---

The calling conventions for each of the supported language and processor type is documented in the respective language on MSDN, e.g: http://msdn2.microsoft.com/en-us/lib...58(VS.71).aspx

For C/C++ 32-bit x86 it is roughly (I wrote that before looking at MSDN):
EAX - return value, otherwise scratch register.
EDX - upper 32-bits of 64-bit return value, otherwise scratch register.
ECX - this when using "thiscall", otherwise scratch.
EBX - preserved by callee.
EDI - preserved by callee.
ESI - preserved by callee.
EBP - preserved by callee.
ESP - stack pointer - varying between call form whether caller or callee cleans up arguments.

I think EAX, EDX and ECX are used for the three first args in "fastcall" calling convention - but I may be wrong on the exact registers.

--
Mats

Quote:

---

Originally Posted by matsp

I think EAX, EDX and ECX are used for the three first args in "fastcall" calling convention - but I may be wrong on the exact registers.

---

That's gcc I believe. W32 passes them in ECX, EDX order.

Quote:

---

Originally Posted by Mario F.

That's gcc I believe. W32 passes them in ECX, EDX order.

---

Quite right - clicking on the "fastcall" link in the page I posted a link to will show that.

--
Mats

Thanks CornedBee,


1.

ABI is short for? :-)

2.

My assembly book is pretty old -- IBM 80x86 book. Could you recommend some assembly language book which conforms (more) to modern compiler and runtime, especially Win32/Win64? I would like to buy a new one after having discussion in this thread with you.

Quote:

---

Originally Posted by CornedBee

The probably have an ABI guide somewhere, but they'd be pretty stupid to document anything beyond that.

---

regards,
George

Quote:

---

ABI is short for?

---

Application Binary Interface

In other words, the low-level conventions program code must follow in order to interoperate with other code.

No idea about assembly books. I never had one. All information I need I take directly from Intel's tech reference.

Quote:

---

Originally Posted by CornedBee

In other words, the low-level conventions program code must follow in order to interoperate with other code.

No idea about assembly books. I never had one. All information I need I take directly from Intel's tech reference.

---

And if you don't want Intel manuals, AMD has a complete set of 5 books (in PDF unless you have GOOD contacts within AMD to get you the hardcopy version). Here for the soft copies.

--
Mats

And here's the Intel variant of pretty much the same thing.

Thanks CornedBee,


Well. I think I have not made myself understood. I think there should be some assembly language manual provided by Microsoft other than by AMD/Intel, because I think to decide ECX should contain this pointer should be decided by Microsoft compiler, right?

What I want is general assembly language + specific things for Windows platform, like ECX for this.

Quote:

---

Originally Posted by CornedBee

And here's the Intel variant of pretty much the same thing.

---

Thanks laserlight,

Quote:

---

Originally Posted by laserlight

Application Binary Interface

---

Is there a book for that? On MSDN or?


regards,
George

Quote:

---

I think there should be some assembly language manual provided by Microsoft

---

You're looking for the ABI description. This has very little to do with assembly language, so an assembly language manual by Microsoft doesn't make sense.

I'm not sure such a thing exists. Microsoft certainly wouldn't go round and write a book that contains all the info from AMD & Intel. On the other hand, AMD & Intel won't reproduce the ABI from Windows or Linux. I don't know if there is a proper documented ABI published by MS, but Linux certainly have a document that describes the ABI.

Searching Amazon.co.uk for "assembler Windows", it gives only two titles, and both are 15+ years old. "Intel Assembler" gives 43 titles, some of which are pretty recent, "AMD Assembler" gives one title in German. I doubt any of these books are particularly targetting Windows programming - once you know how to program assembler in general, using Windows calls is just a case of applying the ABI to function calls, after all.


In lack of such a document, the calling convention is reasonably well described on the page I linked to.

Edit: Note to self: Don't write so much, then CorneedBee won't get there first :)

--
Mats

Hi Mats and CorneedBee,


Could this one be treated as ABI manual by Microsoft?

http://www.microsoft.com/whdc/system...re/PECOFF.mspx

Quote:

---

Originally Posted by matsp

I'm not sure such a thing exists. Microsoft certainly wouldn't go round and write a book that contains all the info from AMD & Intel. On the other hand, AMD & Intel won't reproduce the ABI from Windows or Linux. I don't know if there is a proper documented ABI published by MS, but Linux certainly have a document that describes the ABI.

Searching Amazon.co.uk for "assembler Windows", it gives only two titles, and both are 15+ years old. "Intel Assembler" gives 43 titles, some of which are pretty recent, "AMD Assembler" gives one title in German. I doubt any of these books are particularly targetting Windows programming - once you know how to program assembler in general, using Windows calls is just a case of applying the ABI to function calls, after all.


In lack of such a document, the calling convention is reasonably well described on the page I linked to.

Edit: Note to self: Don't write so much, then CorneedBee won't get there first :)

--
Mats

---

regards,
George

Possibly, but I don't think so. This describes the binary file formats, not the binary interfaces.

No, that describes the format of the executable file, not calling conventions etc.

Here's a link to one page that described calling conventions:
http://msdn2.microsoft.com/en-us/library/aa235581.aspx

This link is one level above the previous one, and covers a whole host of further topics that may be interesting, such as inline assembler usage etc.
http://msdn2.microsoft.com/en-us/lib...8VS.60%29.aspx

--
Mats

Hi Mats,


What do you think is the difference between the PE binary format and the binary guide for calling convetion.

1. Executable is consisting of functions, functions' binary format should be covered in PE (I think it should also cover the assembly code or binary format about the code to invoke a function);

2. Calling convention is about how internally (including the binary assembly code) a function is called.

So, in this way I do not think there is something you are mentioned which is not covered as a part of PE binary format Spec.

Maybe I have not clearly understood your points. What are your ideas?

Quote:

---

Originally Posted by matsp

No, that describes the format of the executable file, not calling conventions etc.

Here's a link to one page that described calling conventions:
http://msdn2.microsoft.com/en-us/library/aa235581.aspx

This link is one level above the previous one, and covers a whole host of further topics that may be interesting, such as inline assembler usage etc.
http://msdn2.microsoft.com/en-us/lib...8VS.60%29.aspx

--
Mats

---

regards,
George

I expect that not to be the case - the executable format has very little to do with the calling convention - it may state that standard DLL's should use stdcall calling convention, but if you really want to you can create a DLL that uses fastcall, cdecl or thiscall calling convention - or any mixture of all four. The PECOFF manual describes how to relocate an executable file, how to find symbols in it, etc, etc, but not how to use assembler code - that is not part of the PECOFF format itself.

The fact that the executable contains functions is for most purposes irrelevant (and in fact, the executable may only contain one function that never calls any other function).

I have a feeling that Microsoft doesn't have a ABI specification. A quick search doesn't find anything at all.

--
Mats

Interesting, Mats!


What topics do you expect the so-called ABI manual for Windows to have?

Quote:

---

Originally Posted by matsp

I expect that not to be the case - the executable format has very little to do with the calling convention - it may state that standard DLL's should use stdcall calling convention, but if you really want to you can create a DLL that uses fastcall, cdecl or thiscall calling convention - or any mixture of all four. The PECOFF manual describes how to relocate an executable file, how to find symbols in it, etc, etc, but not how to use assembler code - that is not part of the PECOFF format itself.

The fact that the executable contains functions is for most purposes irrelevant (and in fact, the executable may only contain one function that never calls any other function).

I have a feeling that Microsoft doesn't have a ABI specification. A quick search doesn't find anything at all.

--
Mats

---

regards,
George

An ABI manual will describe the state before & after function calls, such as which registers are used for what, which registers are caller save, callee save and which are "scratch" registers [that is, the ones that aren't saved by caller or callee, so will change over a function call].

It will also describe things like "how to unwind the stack during exception handling" and such things.

There are a heap of ABI specs on this page:
https://www.linux-foundation.org/dba...e/standard.php

--
Mats

To put it simply, calling convention is a set of rules of how arguments are passed, on the stack or in some registers, in what order the arguments are passed, which function cleans the stack, etc.
MS uses 4 of them: __cdecl, __stdcall, __fastcall and __thiscall.

Thanks matsp and Elysia,


I have got your ideas. Seems there is no open document (including some internal documents on Microsoft System Journal) covers the details in calling convention?

Quote:

---

Originally Posted by Elysia

To put it simply, calling convention is a set of rules of how arguments are passed, on the stack or in some registers, in what order the arguments are passed, which function cleans the stack, etc.
MS uses 4 of them: __cdecl, __stdcall, __fastcall and __thiscall.

---

regards,
George

No, for calling conventions there is. Mats posted a link:
http://msdn2.microsoft.com/en-us/lib...ks(VS.71).aspx

For ABI, there probably isn't.

Thanks Elysia,


What I mean is the binary (assembly language level) description of calling convention.

Quote:

---

Originally Posted by Elysia

No, for calling conventions there is. Mats posted a link:
http://msdn2.microsoft.com/en-us/lib...ks(VS.71).aspx

For ABI, there probably isn't.

---

regards,
George

Quote:

---

Originally Posted by George2

Thanks Elysia,


What I mean is the binary (assembly language level) description of calling convention.




regards,
George

---

It is described in the link - what else do you think EAX, ECX, EDX etc refers to, if not assembler instructions.

If you don't understand how to interpret the calling conventions, perhaps you should study assembler programming in general for a little bit.

--
Mats

Thanks for your patience help on this thread, Mats!

Quote:

---

Originally Posted by matsp

It is described in the link - what else do you think EAX, ECX, EDX etc refers to, if not assembler instructions.

If you don't understand how to interpret the calling conventions, perhaps you should study assembler programming in general for a little bit.

--
Mats

---

regards,
George