[.net] CIL Reflection problem.
Author
I have a fairly interesting problem that I have a fair enough idea how to approach, but could use some pointers from people with more experience, or if this has already been done elsewhere.
So the problem in a nutshell: I want a method that takes a System.Reflection.MethodBody and returns a bool if it is const; that is [at this point] if the only variables it modifies are parameters and/or locals.
So generally it seems as though going through the IL stream and looking at store ops and recursively checking method calls (except where the method is already being checked) is the straightforward/naive approach. Thoughts, opinions, linkies?
If you intend to do that for your own code, you can decorate the methods with a custom attribute and look for the attribute via reflection later.
If you intend to do that for other code, I can't think of another way to do it except for the way you already thought about.
If you intend to do that for other code, I can't think of another way to do it except for the way you already thought about.
Interesting problem. I've worked on a project that involved CIL disassembly, so hopefully I can be of assistance.
If you haven't done so already, you'll want to read the ECMA-335 spec partitions I and III. You can get them here. They're actually pretty interesting reads anyway.
I believe there's some libraries out there that will assist in the disassembly process, but google as I might, I can't find the one I remember seeing last year. If you can find one though, I'd recommend it, as .NET as of now does not have any facilities for programmatically manipulating a pre-existing CIL stream. MethodBase.GetMethodBody().GetILAsByteArray() is all you get, and you have to disassemble it yourself. My project was doing some strange things with the CIL so I ended up having to do that, but for tackling this problem there's probably some code out there that will get you on your way pretty fast. Codeproject would probably be a good place to check.
If you want to roll your own, here's some tips that might help. CIL is pure stack machine with no registers, which makes it very easy to work with. Furthermore, the specification dictates that the state of the stack (how many objects are on it and what types they are) can be determined by a simple linear pass of the code. This means your code does NOT have to follow backwards control flow and try to detect strange situations where the stack keeps growing or anything like that. This will allow you to quickly find all the places in a method where objects of the same type as your parameters are being modified (figuring out if they actually are the arguments or not will be a bit more complex).
Of course, if as cobru mentioned, this is only for your own code, all of this becomes moot. :) Anyway, working with CIL is pretty interesting and I enjoy mulling over the topic, so if you have any other questions about it, shoot.
If you haven't done so already, you'll want to read the ECMA-335 spec partitions I and III. You can get them here. They're actually pretty interesting reads anyway.
I believe there's some libraries out there that will assist in the disassembly process, but google as I might, I can't find the one I remember seeing last year. If you can find one though, I'd recommend it, as .NET as of now does not have any facilities for programmatically manipulating a pre-existing CIL stream. MethodBase.GetMethodBody().GetILAsByteArray() is all you get, and you have to disassemble it yourself. My project was doing some strange things with the CIL so I ended up having to do that, but for tackling this problem there's probably some code out there that will get you on your way pretty fast. Codeproject would probably be a good place to check.
If you want to roll your own, here's some tips that might help. CIL is pure stack machine with no registers, which makes it very easy to work with. Furthermore, the specification dictates that the state of the stack (how many objects are on it and what types they are) can be determined by a simple linear pass of the code. This means your code does NOT have to follow backwards control flow and try to detect strange situations where the stack keeps growing or anything like that. This will allow you to quickly find all the places in a method where objects of the same type as your parameters are being modified (figuring out if they actually are the arguments or not will be a bit more complex).
Of course, if as cobru mentioned, this is only for your own code, all of this becomes moot. :) Anyway, working with CIL is pretty interesting and I enjoy mulling over the topic, so if you have any other questions about it, shoot.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
