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,972 | Comments: 44,508

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

  1. Paying the rent online - 9 hours from now
  2. Reducing parsing costs in RavenDB - about one day from now

There are posts all the way to Aug 04, 2015

RECENT SERIES

  1. Production postmortem (5):
    29 Jul 2015 - The evil licensing code
  2. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
  3. API Design (7):
    20 Jul 2015 - We’ll let the users sort it out
  4. What is new in RavenDB 3.5 (3):
    15 Jul 2015 - Exploring data in the dark
  5. The RavenDB Comic Strip (3):
    28 May 2015 - Part III – High availability & sleeping soundly
View all series

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats