1. Yes, it is for arg iterator to work. This code could use some
cleanup.
2. This code is building the layout of the FramedMethodFrame C++ class
on the stack one word at a time. The Frame vtable is used to call
virtual methods, e.g. Frame::GcScanRoots.
3. m_Next is uninitialized space at this point in the code. It will be
initialized later as the frame is linked into the linked list of frames
on Thread.
Here is the matching code in vm\i386\cgenx86.cpp:
VOID StubLinkerCPU::EmitMethodStubProlog(LPVOID pFrameVptr)
{
THROWSCOMPLUSEXCEPTION();
// push edx ;leave room for m_next (edx is an arbitrary choice)
X86EmitPushReg(kEDX);
// push Frame vptr
X86EmitPushImm32((UINT)(size_t)pFrameVptr);
-Jan
-----Original Message-----
From: Discussion of the Rotor Shared Source CLI implementation
[mailto:[EMAIL PROTECTED] On Behalf Of Kaushik
Srenevasan
Sent: Wednesday, September 07, 2005 9:08 AM
To: DOTNET-ROTOR@DISCUSS.DEVELOP.COM
Subject: [DOTNET-ROTOR] Rotor method frame questions
Hi,
I have a couple of questions about FramedMethodFrame and the JIT thunk
1. Why does MethodDesc::CallDescr construct a fake FramedMethodFrame
instance on the stack? Is it for the arg iterator to work?
2. In the JIT thunk, the instruction following push edx, pushes an
addresses
onto the stack. This looks like it is a pointer to the VTABLE of a Frame
derived C++ class. What is this used for ?
3. The 4 bytes just above this value in the stack (m_Next) is used to
store
an address which looks like another pointer to a VTABLE. What is this
used
for?
Thanks,
Kaushik Srenevasan
===================================
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
