Do I need to write my own unmanaged IL library to rewrite IL with the CLR Profiling API?

Question

I've been looking at some of the articles for the CLR Profiling API, and many of those articles talk about calling SetILFunctionBody() to do the actual IL rewriting; however, none of those articles actually explain exactly what you could use to rewrite the actual method IL bytes. Is there an unmanaged library out there that allows me to write IL, or would I have to write one myself?

Answer 1

I assume you want to do this because you want to see what is taking time so that you can make it go faster (as opposed to just getting various timing info). IMHO, you don't need the profiling API, if you can run your app under an IDE and pause it at random. Here's why.

Answer 2

The actual bytes has to come from somewhere and if you are just using the Profiling API then you must provide them yourself. This article goes in-depth on how to do it (probably one of those you have read): http://msdn.microsoft.com/en-us/magazine/cc188743.aspx

A more 'common' technique is to actually write whatever code you need in whatever language you prefer and then compile it to IL. You can then either extract the OpCodes at design-time and store them where you can reach them or extract them from your compiled IL at run-time and stuff it where you need it.

AFAIK there are no unmanaged libraries to help you with this.

Answer 3

This article may have what you are looking for http://www.codeproject.com/KB/cs/IL_Rewriting.aspx

Answer 4

Probably. It depends.

The Mono Project has a library called Cecil, which you can access here:

http://mono-project.com/Cecil

However it's managed code, which you can't call while profiling. You may a have a few options though:

1. Use IPC. You could spawn a new process, doing the rewriting using cecil in that process and then pass the bytes back to your profiler using named pipes.
2. Port CECIL to C++. The code's distributed under the MIT / X11 license, so you could do this without having to share your changes.
3. Just write your own stuff from scratch.

#1 introduces a bunch of extra complexity. Your profiler would end up having more moving parts than it really needed. Also, the IPC introduces a bunch of extra overhead.

#2 would take a long time. Given that Cecil is still only at version 0.6, it might not be worth the time to do it, vs writing your own implementation.

#3 would give you the greatest degree of control, and would probably be the most performant. However it would take substantially more effort than #1 would.