Re: Virtual calls

Here is the picture:

Object:                   MethodTable:
++++++++++++++++          +++++++++++++++++++++++      +
| MethodTable* |   --->   | DWORD m_wFlags      |      |
++++++++++++++++          | DWORD m_BaseSize    |      |
+ ...          |          | EEClass* m_pEEClass |      |
+              |          | other fixed members |      |
++++++++++++++++          +++++++++++++++++++++++      |
                          + slot #0             |      |
                          +++++++++++++++++++++++      |
                          + slot #1             |      |
                          +++++++++++++++++++++++      V
                          + slot #2             |   ------>
                          +++++++++++++++++++++++
                          + slot #3             |
                          +++++++++++++++++++++++
                          + slot #4             |
                          +++++++++++++++++++++++

getMethodVTableOffset returns offset of the slot in MethodTable*. It =
computes it by adding the size of the fixed members and method slot =
multiplied by slot size.

The code emitted for virtual call fetches MethodTable* by derefencing =
thisptr into the CALLREG register. methodVTableOffset is added and the =
result is *dereferenced* again to get the target code address.

method->GetAddrofcode(ObjectToOBJECTREF(thisObj)); should give you the =
same code address. You may be confusing the value in the slot and the =
address of the slot. GetAddrofcode returns the value in the slot.

-Jan

-----Original Message-----
From: Discussion of the Rotor Shared Source CLI implementation =
[mailto:[email protected]] On Behalf Of J. Redondo
Sent: Tuesday, March 29, 2005 1:39 AM
To: [email protected]
Subject: [DOTNET-ROTOR] Virtual calls

Hello,

I'm a little confused about how method calls are transformed by the =
jitter
into native code. I can see clearly now that two different cases are
distinguished: non-virtual calls and virtual calls. When dealing with =
the
former, only a method entry point is needed, which is obtained directly =
from
the slot of the class method table in most cases. This entry point is =
stored
in the CALLREG register and the call is done. However, the latter is =
giving
some trouble to me, because now three values are taken into account:

- The method slot, which is obtained directly from an attribute of the
MethodDesc class.
- A Method Table offset. I assumed that this value was the location of a
pointer to the class method table (table that is common to all the class
objects), but now I'm not so sure about it.
- A third value that the Jitter function buildCall stores in ARG_1 or =
ARG_2.
I wasn't able to find what did it represent (this pointer?).

The two first values are added in jitinterface code and the result is =
later
added to the CALLREG register that stores the third, doing the call with
that final result. The problem is that, as you can see, I wasn't able to
know the meaning of some values so I couldn't fully understand how Rotor
accesses virtual methods. I'm also trying to find how can this address =
be
calculated accessing only to the metadata structures (like introspection
MethodInfo.Invoke calls should do). I tried to do the following:

method->GetAddrofcode(ObjectToOBJECTREF(thisObj));

But I'm not obtaining the same value that is used by the jitter in the
virtual calls. =BFAm I forgetting or misunderstanding something? =BFCan =
anybody
give me some help?

Thank you very much in advance,

Jose M.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
This list is hosted by DevelopMentor=AE  http://www.develop.com

View archives and manage your subscription(s) at =
http://discuss.develop.com

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
This list is hosted by DevelopMentor=AE  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com