Many stubs heavily depend on the exact layout of FramedMethodFrame. The first place you are likely to hit is the stub prolog generation in StubLinkerCPU::EmitMethodStubProlog. My guess is that there are probably half-dozen more places that need to be fixed up if you modify FramedMethodFrame. I have hint for you: add your new members to the top of FramedMethodFrame, not to the bottom of FramedMethodFrame - the modifications of the stubs will be easier to do this way.
I don't think you can ignore asserts in Binder::CheckMscorlib. They are telling you that the class layout is not what you expect. The calculation of the field offsets in EEClass::InitializeFieldDescs is where to start looking for the source of this problem. You are likely to hit quite a few problems along the way if you try to add the new member to the base object though. I don't know what you are trying to achieve with the new member, but I would suggest to try one of the following alternatives: 1. add the new member to class SyncBlock. SyncBlock can be created on demand for any object by Object::GetSyncBlock(). 2. create a new type inheriting from Object in the class hierarchy that will have the data you need, and make the objects that take advantage of your new functionality to inherit from this new type. This pattern is used on several places in the runtime already - MarshalByRefObject is the best example. -Jan This posting is provided "AS IS" with no warranties, and confers no rights. -----Original Message----- From: Iv�n Su�rez [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 15, 2003 10:00 AM To: [EMAIL PROTECTED] Subject: [DOTNET-ROTOR] Problems with FramedMethodFrame I am changing the class FramedMethodFrame, because I want add a field after m_ReturnAddress attribute. I have changed this class in files clr\src\vm\frames.h and clr\src\tools\sos\Tst-frames.h. I have changed struct prolog_frame too. I have added the field (a void pointer) to the three data structs after the m_ReturnAddress attribute. The problem is that I get an error. This error seems to be an runtime error in jitted code, because it is not an assert. The message that appears is "Application has generated an exception that could not be handled", and this application is the csc compiler. With the modification of the Object class I have other problem. I have modified the value of the macro MIN_OBJECT_SIZE, and I added a field to class Object in clr\src\Object.h, to struct CORINFO_Object in corinfo.h and to BaseObject in clr\src\tools\sos\Strikee.h. I get some ASSERTS of the method Binder::CheckMscorlib(), Can I ignore it supposing that the Rotor calcutes the new offsets right? Could anyone help me? Thanks Iv�n Su�rez Oviedo University
