[Mono-dev] Debugging Busted CIL

[Paolo Molaro]

On 10/04/05 Jim Purbrick wrote:
> The StackBehaviourPush of the ldflda instruction
> returns pushi, so I try to store the result in an
> int32, but MSDN
> (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemreflectionemitopcodesclassldfldatopic.asp)
> and the ECMA specs
> (http://dotnet.di.unipi.it/EcmaSpec/PartitionIII/cont4.html#_Toc526908960)
> both state that ldflda pushes a Managed Pointer on to
> the stack (which is presumably why pedump is
> complaining when I try to store the result in an
> Int32).

A managed pointer fits into an int32 only on 32 bit system.

> Is is possible to store and load Managed Pointers in
> CIL? How?

Storing them in a local of the correct type.

On 10/04/05 Jim Purbrick wrote:
> > Is is possible to store and load Managed Pointers in
> > CIL? How?
> 
> Sorry, should have googled a bit more before my last
> post.
> 
> Looks like I can store a Managed Pointer in a local,
> but not a field :-(

Right, storing in a field would have both security and performance
effects in the GC, so it's not allowed.

> http://dotnet.di.unipi.it/EcmaSpec/PartitionIII/cont1.html#_Toc526908860
> 
> Looks like I won't be able to yield whenever there is
> a Managed Pointer on the stack :-(
> 
> Do any other ops push Managed Pointers (and then claim
> that their StackBehaviourPush is pushi?)

ldarga, ldloca, ldelema are other examples of opcodes that create
managed pointers.

> Can anyone see a way around this?

First, it depends what kind of managed pointers we are talking about,
stack-based or heap-based.
Saving managed pointers to stack locations is not safe at all, because
they are gone as soon as you exit the current stack frame.
For heap-based managed pointers you could store them in an intptr field
after the object they belong to is pinned. From C# code there is a
facility to pin objects, but it's limited. Since you embed Mono, IIRC,
you could add an icall to pin any object (with a call to: 
	handle = mono_gchandle_new (obj, TRUE);
).
Note that pinning lots of objects for long time will have a bad effect
on the GC (not the current one, though).
Pinning will make sure that the object doesn't move and that it won't be
collected, so saving the value will be correct, while it still won't
be verifiable. This latter issue could be dealt with, since you have
complete control of it.
Make sure you free the handle when done.
Hope this helps.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better