plnelson
commented
7 years ago Yes, calculating the result of an expression in many cases will require temporary variables. The C# Expression Compiler will in fact use temporaries sometimes. The documentation was incorrect so I corrected it.
In a nutshell, you can define and use temporary variables as long as they are after all of the locals defined in the original method.
In terms of the other behaviors you were seeing:
- "Code works in the "root frame", but doesn't work in methods called by the root frame."
Essentially what is happening is the debugger uses an emulator to interpret the code generated for the expression. This emulator is very limited in terms of the code it can execute. A few of the limitations are: can't execute P-Invokes (with a few exceptions), can't find the target method of a real delegate, can't call methods/properties on real System.Type and types in System.Reflection. By "real", I mean a value from the debuggee process rather than a value created in the emulator.
The reason most evaluations work is because the debugger will try to execute calls made in the root frame in the debuggee process itself rather than try to emulate the call. We call execution of the method in-process "func eval". With few exceptions, we only func eval from the root frame of the evaluation. The reasons for this get really complicated so I'll skip that subject for now.
With this knowledge, another solution you can use (besides temporaries) is to have your compiler/runtime put these helper methods in the process itself rather than the query assembly. If the method lives in the process, the debugger can func eval it.
- "System.Array.CreateInstance doesn't always work"
It works from the root frame because the debugger will func eval it as described above. If it's not in the root frame, the emulator has to execute it, and the emulator doesn't support this method. One experiment you can do is force the emulator to be used and get an idea of what the problem is. You can force the emulator by using the "emulator" format specifier. An example from the Immediate window in VS:
Array.CreateInstance(typeof(string), 10),emulator
Evaluation of method System.Array.CreateInstance requires reading field System.IntPtr.m_value, which is not available in this context.Without going into too much detail, Array.CreateInstance would need to be special cased in order to emulate it. This was probably never done because Array.CreateInstance is rarely used.
Generally instead of:
call class [mscorlib]System.Type [mscorlib]System.Type::GetTypeFromHandle(valuetype [mscorlib]System.RuntimeTypeHandle)
ldc.i4.s 10
call class [mscorlib]System.Array [mscorlib]System.Array::CreateInstance(class [mscorlib]System.Type, int32)The compiler will generate:
ldc.i4.s 10
newarr stringOf course, that will only work for a single dimension array. If you to create and initialize a multi-dimensional array you can use RuntimeHelpers.InitializeArray. Here's an example of creating and initializing a more complicated array:
ldc.i4.s 10
ldc.i4.s 10
newobj instance void int32[0..., 0...]::ctor(int32, int32)
ldtoken field valuetype [mylib]MyCompilerGeneratedField::MyArrayData1
call void [mscorlib]System.Runtime.CompilerServices.RuntimeHelpers::InitializeArray(
class [mscorlib]System.Array,
valuetype [mscorlib]System.RuntimeFieldHandle)
The emulator will be able to handle the last two code snippets. Hopefully that helps. Let me know if you have any other questions.
-Patrick
onor13
When generating the MSIL file to get the locals variables, based on the doc from here https://github.com/Microsoft/ConcordExtensibilitySamples/wiki/CLR-Expression-Evaluators, I found a bug/limitation. The documentation says and I quote:
But what if the MSIL needed to compute a variable is very complex and requires additional local variables? A natural solution to bypass this limitation is to use a call an intermediate function that does all necessary work. So the code would look something like that:
The code above works fine (If I didn’t make a typo when writing it). But when I try to do something more complex in my MyMethod sometimes it fails and I can’t understand why. Now let’s look at 2 cases where it fails for the reasons I don’t understand: 1) To somehow debug I created a logger that uses a TextWriter class to write to some file. The call to the logger looks something like
When I place the call to the logger in the "M1" method everything works fine, but if I put the same call in the "MyMethod" method, I get an exception:
Why the same call works in “M1” and not in “MyMethod”??? It looks like for some reasons I am more limited in the library usage in “MyMethod”. 2) The second example and the main reason why I created this topic is that I want “MyMethod” to return System.Array. Let’s take the example from above and replace int32 by System.Array:
As you can see this code is very similar to the first example but in this case we create a System.Array of size 10. For some unknown reasons it does not work: the value, the name and the type for the specified local is blank in the debugger local window. If we inline the “MyMethod” call, everything works fine. Again, it looks like making call to an intermediate functions creates a bug. Here is the inline version that works correctly: