Ayende @ Rahien

Hi!
My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:

ayende@ayende.com

+972 52-548-6969

, @ Q c

Posts: 5,953 | Comments: 44,410

filter by tags archive

System.Reflection.Emit fun: Find the differences


This is annoying, I am trying to make something like this works using SRE:

public void Foo(out T blah)
{
    blah = (T)Arguments[0];
}

I created the SRE code to generate the appropriate values, but it is producing invalid code.

Works, but not verified IL:

    L_0089: stloc.2
    L_008a: ldarg.1
    L_008b: ldloc.2
    L_008c: ldc.i4 0
    L_0091: ldelem.ref
    L_0092: unbox.any !!T
    L_0097: stobj !!T
    L_009c: ret

Works, valid (csc.exe output, of course):

    L_000d: stloc.1
    L_000e: ldarg.1
    L_000f: ldloc.1
    L_0010: ldc.i4.0
    L_0011: ldelem.ref
    L_0012: unbox.any !!T
    L_0017: stobj !!T
    L_001c: ret

And yes, the stloc.2, and stloc.1 are expected.

Comments

Jeremy Gray

I don't often work down at that low of a level, but the ldloc difference stood out to me. Related to your issue, perhaps? (not that I would be in a position to say how ;)

Jeremy Gray

Err, brain-fart on my part.: when I said "ldloc difference" I meant to say "ldarg versus ldloc difference across examples 1 and 2".

:)

Neal Blomfield

Assuming the difference between equivalent lines L008c and L0010 is a typo (and ignoring that your generated code uses an extra variable), there does not seem to be any difference at all between these 2.

Can you create a valid implementation with SRE that mimics the valid example exactly (i.e. no variations in args or variables)?

Hoping you find the issue and curious as to what has caused it.

Steve

L0010 is a shorthand version of L008c.

According to the documentation they should behave identically.

Is there some undocumented difference?

Dennis

L_008c: ldc.i4 0 <-- 40

L_0010: ldc.i4.0 <-- 40

Ayende Rahien

This is the same think.

The second is a way to specify this with one less byte/int

liviu

Maybe,

the error is in the code you don't show. In the way you defined your local variables, etc...

I played with reflection emit a lot lately (not so much with generics) and i know that finding the problems is really hard, the dreadfull Invalid program Exception is so useless...

runefs

aside from you using the 8 byte nonconstant version of ldc.i4 instead of the constant, asuming that local2 has the same type as local1 there's no difference in the two snippets. since ldc.i4 0 is not invalid that should not be the problem. If run peverify on the code what's the error message?

Fabian Schmied

With SRE, it's often easy to confuse generic parameter references: when you define a generic parameter, you must always refer to that parameter using the returned GenericTypeParameterBuilder, even if you think you have found some other way to get to the same parameter. That has bitten us a few times within DynamicProxy already.

I tried, and I think I managed to get an implementation of your problem that works:

using System;

using System.Reflection.Emit;

using System.Reflection;

namespace ConsoleApplication46

{

class Program

{

static void Main (string[] args)

{

  var name = new AssemblyName ("MyAssembly");

  AssemblyBuilder assemblyBuilder = AppDomain.CurrentDomain.DefineDynamicAssembly (name, AssemblyBuilderAccess.RunAndSave);

  ModuleBuilder moduleBuilder = assemblyBuilder.DefineDynamicModule ("MyAssembly.dll");

  TypeBuilder typeBuilder = moduleBuilder.DefineType ("Generated", TypeAttributes.Public);

  GenericTypeParameterBuilder[] genericParameterBuilders = typeBuilder.DefineGenericParameters ("T");

  FieldBuilder argumentsFieldBuilder = typeBuilder.DefineField ("Arguments", typeof (object[]), FieldAttributes.Public);

  MethodBuilder fooMethodBuilder = typeBuilder.DefineMethod ("Foo", MethodAttributes.Public);

  fooMethodBuilder.SetParameters (genericParameterBuilders[0].MakeByRefType ());

  fooMethodBuilder.DefineParameter (1, ParameterAttributes.Out, "blah");

  ILGenerator ilGenerator = fooMethodBuilder.GetILGenerator ();


  ilGenerator.Emit (OpCodes.Ldarg_1);

  ilGenerator.Emit (OpCodes.Ldarg_0);

  ilGenerator.Emit (OpCodes.Ldfld, argumentsFieldBuilder);

  ilGenerator.Emit (OpCodes.Ldc_I4_0);

  ilGenerator.Emit (OpCodes.Ldelem_Ref);

  ilGenerator.Emit (OpCodes.Unbox_Any, genericParameterBuilders[0]);

  ilGenerator.Emit (OpCodes.Stobj, genericParameterBuilders[0]);

  ilGenerator.Emit (OpCodes.Ret);


  typeBuilder.CreateType ();


  assemblyBuilder.Save ("MyAssembly.dll");

}


class Reference<T>

{

  public object[] Arguments;


  public void Foo (out T blah)

  {

    blah = (T) Arguments[0];

  }

}

}

}

Although, judging from the "!!T" in your disassembly, did you mean Foo? Then it would be as follows:

var name = new AssemblyName ("MyAssembly");

  AssemblyBuilder assemblyBuilder = AppDomain.CurrentDomain.DefineDynamicAssembly (name, AssemblyBuilderAccess.RunAndSave);

  ModuleBuilder moduleBuilder = assemblyBuilder.DefineDynamicModule ("MyAssembly.dll");

  TypeBuilder typeBuilder = moduleBuilder.DefineType ("Generated", TypeAttributes.Public);

  FieldBuilder argumentsFieldBuilder = typeBuilder.DefineField ("Arguments", typeof (object[]), FieldAttributes.Public);

  MethodBuilder fooMethodBuilder = typeBuilder.DefineMethod ("Foo", MethodAttributes.Public);

  GenericTypeParameterBuilder[] genericParameterBuilders = fooMethodBuilder.DefineGenericParameters ("T");

  fooMethodBuilder.SetParameters (genericParameterBuilders[0].MakeByRefType ());

  fooMethodBuilder.DefineParameter (1, ParameterAttributes.Out, "blah");

  ILGenerator ilGenerator = fooMethodBuilder.GetILGenerator ();


  ilGenerator.Emit (OpCodes.Ldarg_1);

  ilGenerator.Emit (OpCodes.Ldarg_0);

  ilGenerator.Emit (OpCodes.Ldfld, argumentsFieldBuilder);

  ilGenerator.Emit (OpCodes.Ldc_I4_0);

  ilGenerator.Emit (OpCodes.Ldelem_Ref);

  ilGenerator.Emit (OpCodes.Unbox_Any, genericParameterBuilders[0]);

  ilGenerator.Emit (OpCodes.Stobj, genericParameterBuilders[0]);

  ilGenerator.Emit (OpCodes.Ret);


  typeBuilder.CreateType ();


  assemblyBuilder.Save ("MyAssembly.dll");

Comment preview

Comments have been closed on this topic.

FUTURE POSTS

No future posts left, oh my!

RECENT SERIES

  1. The RavenDB Comic Strip (3):
    28 May 2015 - Part III – High availability & sleeping soundly
  2. Special Offer (2):
    27 May 2015 - 29% discount for all our products
  3. RavenDB Sharding (3):
    22 May 2015 - Adding a new shard to an existing cluster, splitting the shard
  4. Challenge (45):
    28 Apr 2015 - What is the meaning of this change?
  5. Interview question (2):
    30 Mar 2015 - fix the index
View all series

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats