Author Topic: Object virtual table  (Read 751 times)


  • Full Member
  • ***
  • Posts: 128
Object virtual table
« on: September 25, 2021, 07:38:32 pm »
(I mainly answered my questions. Sorry for asking too fast. Anyway I left my answers next to my questions with CAPITAL).

I am trying to figure out how the virtual table attached to an object is actually structured. What I think I figured out so-far (but please correct me if I am wrong).
The data for the object instance is the actual data fields (with padding) and an extra pointer for the virtual table.
Unlike in C++, there is a virtual table even if no virtual method is used at all. I guess it is because the implicitly generated destructor is always virtual. (IT SEEMS NOT, NEED ANOTHER ANSWER).
The pointer that point to the virtual table is the last data.
I would expect that the virtual table is a TVmt record (, on x86 200 bytes. My problem is that I have two objects and their vmt -s follow each other by 56 bytes. This confuses me a lot:
- Why is it not 200 bytes as per the documentation? (SOLVED - THAT IS FOR CLASSES ONLY)
- How can it be aligned to 64 bits, when elsewhere I see alignment to 128 bits - see my other question, please? (IT IS ALIGNED TO 64 BITS)
- What is in these 56 bytes (7 x 64 bits data)?
For the last question, I tried to figure out, based on the tVmt description:
1., 2. The first 2 data meets the description of tVmt, i.e. vInstanceSize and minus vInstanceSize (aka vInstanceSize2).
3. The next one should be a pointer called the parent reference. As far as I can see this pointer points to the 7th data of the parent's vmt if a parent exists, otherwise nil.
4. The fourth data should be the class name, but it is clearly not. It seems to point to the table of the actual entry points of the virtual methods, but I am not sure.
5. The fifth data should be the "dynamic table" (does it still exist, or is it a Delphi heritage only?), but in my tests they pointed all to somewhere around the parent object. I do not see what is it.

6. The six so-far was always zero. I am not sure if it is data with 0 value or is it actually a 128 bit padding of the data so-far.
7. The seventh is a pointer, pointing back to the first element. This is also published in the .o file as VMT_$MANGLEP_$$_<objecttype>$indirect. I am  ot sure, what is the benefit of having this indirect reference, but as mentioned above, all children point to this indirect pointer and not to the beginning of the table. If the 6th is a padding and this is an independent data, even then I do not fully get, why this is not padded to 128 bits (like many other things), because the next object's similar data starts immediately after this (i.e. this pointer is 64 bits unaligned, unpadded).
Can someone help me to understand it better?

P.S. In the meantime I figured out that the mentioned Vmt is for classes only. For objects I found a 32 bit description in, but not one for 64 bits.

P.P.S. Sorry, I was too fast. I also found the 64 bit one. So, if I am not mistaken the 4th, 5th data are already the entrypoints to the virtual methods, and they go as many virtual methods there are. After the last one there is always a nil pointer (in my example it was the 6th, but it can be more or less). After the nil pointer comes the indirect pointer pointing back to the beginning.
« Last Edit: September 25, 2021, 08:03:02 pm by jollytall »


TinyPortal © 2005-2018