[Mono-dev] Cecil.FlowAnalysis and exception handler blocks

Aaron Tomb atomb at soe.ucsc.edu
Sun Jun 4 23:28:17 EDT 2006


There's some code in the null dereference analysis portion of Gendarme
that deals with control flow graphs, with some minimal (and possibly
incorrect) support for exceptions. It might be worth looking at, however
incomplete it is.

Also, if Cecil.FlowAnalysis.ControlFlow gets to the point where it can
handle exceptions well, it might be worth updating the null dereference
code to use it, instead of the CFG code I wrote.

Aaron

On Sun, Jun 04, 2006 at 02:50:52PM -0400, Russell Morris wrote:
> Hi all,
> 
> I'd like to update the code in Cecil.FlowAnalysis.ControlFlow so that it 
> can make sense of exception handling blocks.  Currently, the 
> FlowGraphBuilder in here refuses to deal with functions that have 
> exception handling blocks.
> 
> At first glance, I think that a new class would be introduced to 
> represent the exception handling blocks themselves.  This new class 
> would contain information about the type of exception handling block it 
> represented (catch, fault, finally, or filter), and a pointer to one (or 
> more for catch blocks) InstructionBlocks that served as the entry point 
> to the handler(s).
> 
> Each InstructionBlock would also have a reference to a lookup table that 
> could return a stack of exception handling block classes (mentioned 
> above) for any given instruction in the function.  The stack would 
> represent the exception handler blocks that could potentially be invoked 
> if the given instruction threw an exception (a stack because exception 
> handling blocks can be nested in one another).
> 
> I'm interested in knowing if anyone out there is currently working in 
> this area of Cecil, and would have anything to add to this analysis.
> 
> Thanks,
> 
> Russ
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



More information about the Mono-devel-list mailing list