[Mono-list] Nasty x86_magic_trampoline gremlin: ambiguous call sequences

[Miguel de Icaza]

> Here is what I found in mcs/ecore.cs:
> 
> 		if (FieldInfo is FieldBuilder){
> 			Field f = TypeManager.GetField (FieldInfo);
> 			if (f != null && (f.ModFlags & Modifiers.VOLATILE) != 0)
> 				is_volatile = true;
> 			
> 			f.status |= Field.Status.USED;
> 		}
> 
> For some reason TypeManager.GetField (FieldInfo) returns NULL (ecx)
> and while f != null is checked before inspecting f.ModFlags, it is not
> before setting f.status (I guess status is at offset 0x24 in the Field
> object). So this is an error in mcs for sure. 

What happens there is that the FieldBuilder (A system.reflection.emit
beast that happens also to be a FieldInfo) is being mapped into the
"backing" information that the compiler has for this particular field
(an object of class Field).

We need to do this because there is no other way to extract the
"volatile" flag (reflection does not provide a way to do this).  

So in theory `f' could never be null there, as we should register all
the Field objects with the Type Manager.

Do you have a sample program to reproduce this on Windows?

`f' can only be null there.  I wonder why we even check for null in
there, as the compiler is supposed 

Miguel