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: DOTNET-ROTOR@DISCUSS.DEVELOP.COM
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. ¿Am I forgetting or misunderstanding something? ¿Can anybody
give me some help?

Thank you very much in advance,

Jose M.

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

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

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

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

Reply via email to