Bug! Inspecting Value-Type Returns Workaround #2

re: Bug! Inspecting Value-Type Returns Workaround #2

Marc Brooks — Thu, 08 Jun 2006 00:46:32 GMT

Couldn't you avoid all that signature rewriting by calling into a stub function that _itself_ does a local store to it's (0-indexed always!) local, then call-out to the inspection method? That gives:

// original
ret

// injected
call inspect // dynamic stub
ret

// inspect dynamic stub's body (signature left as exercise to you).
dup
stloc.0 // Copy return value into local
ldloca.0 // Push address to local onto stack
ldc.i4(8) UnmanagedInspectValue (fcn pointer)
calli callsitedescr
ret

re: Bug! Inspecting Value-Type Returns Workaround #2

davbr — Thu, 08 Jun 2006 04:51:38 GMT

I think something like what you propose could work, though it may need some refinement and would probably have worse perf. This is still an interesting idea to explore. Now I haven't tried any of this out, but I suspect the JIT will be unhappy with the IL exactly as you wrote it, due to the IL stack being used in an unbalanced way across the function call. Your "inspect" stub has a dup at the top, but no one explicitly loaded anything onto the stack, so the stack is empty as far as the JIT can tell. Of course, we all know better because we know we'll be good citizens and only call "inspect" right before your rewritten (what you labeled "injected") function returns (so its return value is on the stack). But we're not allowed to be smarter than the JIT--we've got to follow the rules.

Perhaps you wanted "inspect" to take a param, in which case you'd do a "ldarg" just before your "dup". In that case, "call inspect" will expect that param will be on the stack (for "inspect" to use), and it will therefore be popped for you. So by the time you return out of "inspect" back to "injected", the JIT will expect your stack is empty and you have nothing to return.

If you move your "dup" out of "inspect" and into your injected function, and add the missing IL to push the arg back onto the stack, you have this:

// original
ret

// injected
dup
call inspect // dynamic stub
ret

// inspect dynamic stub's body (signature left as exercise to you).
ldarg.0 // Push arg back on stack
stloc.0 // Copy arg into local
ldloca.0 // Push address to local onto stack
ldc.i4(8) UnmanagedInspectValue (fcn pointer)
calli callsitedescr
ret

You could simplify even further by using "ldarga" to load the arg's address onto the stack directly, without needing a local at all:

// inspect dynamic stub's body (signature left as exercise to you).
ldarga.0 // Push address of arg
ldc.i4(8) UnmanagedInspectValue (fcn pointer)
calli callsitedescr
ret

Looks cool, right? But that brings me to this part: "signature left as exercise to you". What exactly is the type of parameter that "inspect" takes? That's quite important to declare to the JIT via metadata. In fact, for every possible value type that can be passed to "inspect", you'll need another override of "inspect" that takes a parameter of that type. This can be prohibitively time-consuming at run-time to create every possible override you need.

That said, maybe this can be worked around by making a single "inspect" function that's vararg? Then again, the extra time it takes to initialize System.ArgIterator so it can fish out the type could again be prohibitive.

re: Bug! Inspecting Value-Type Returns Workaround #2

johnls — Thu, 08 Jun 2006 20:37:28 GMT

It's also important to point out to folks that calli is an unverifiable instruction that requires the UnverifiableCode access permission. Any attempt to use this technique in an assembly that doesn't have FullTrust will fail.

Creating an IL-rewriting profiler

David Broman's CLR Profiling API Blog — Wed, 07 Mar 2007 06:13:22 GMT

A frequent topic of discussion between those of us on the CLR Profiling API team at Microsoft and our

Versions of Microsoft .NET Framework, CLR, and Your Profiler

David Broman's CLR Profiling API Blog — Thu, 06 Dec 2007 20:47:44 GMT

With the recent release of the Microsoft .NET Framework 3.5, not to mention prior versions like Microsoft

Versions of Microsoft .NET Framework, CLR, and Your Profiler

Noticias externas — Thu, 06 Dec 2007 20:51:20 GMT

With the recent release of the Microsoft .NET Framework 3.5, not to mention prior versions like Microsoft

.NET to C++ Bridge

All Your Base Are Belong To Us — Sun, 17 Feb 2008 00:04:50 GMT

Most people have encountered the need for interoperability between managed and unmanaged code. There

re: Bug! Inspecting Value-Type Returns Workaround #2

Tanveer Badar — Sun, 02 Nov 2008 21:37:28 GMT

"However, since in my case I only have one parameter anyway, I can cheat and just call it __fastcall, and the compiler is none the wiser. Just so long as I remember that, once I add a third parameter to my function, the gig is up!"

Perhaps I did wrong math in this case, but it should be the fourth parameter when order starts being significant.

First two parameters are passed in ECX/EDX. Next parameter is on stack. Order doesn't matter. Its when you add fourth parameter you really need to care about C, D or D, C.

re: Bug! Inspecting Value-Type Returns Workaround #2

davbr — Mon, 03 Nov 2008 01:34:17 GMT

Hello, Tanveer. Great point! Yes, if there's only 3 parameters, then there's only 1 stack parameter, and therefore there would be no issue with stack parameter ordering in that case. You are correct that, when one moves up to FOUR parameters total, only then does stack ordering become an issue. Thanks for catching that!