[Soot-list] ExceptionalGraph no longer handles Block graphs (was How to specify the type of control flow graph?)

[Eric Bodden]

Hi John.

This may well have been a mistake. The "genericizing" happened mostly
using the automated support built into Eclipse but in some classes I
assisted by hand and it might well be the case that I have made some
too restrictive assumptions about that class. I will look into the
code tomorrow and let you know.

Eric

2008/5/5 John Jorgensen <jorgnsn at lcd.uregina.ca>:
> >>>>> "cbqios" == bq chan <cbqios at gmail.com> writes:
>
>     cbqios> I wonder that if we can specify the type of
>     cbqios> control flow graph to be dumped.  I can just get dot
>     cbqios> files of jimple unitgraphs, but what I really want is
>     cbqios> those jimple blockgraphs.
>
>  I was going to suggest trying "java soot.util.CFGViewer --help"
>  (with the classpath that you use to run Soot) to see if that will
>  do what you want.  CFGViewer allows you to specify the type of
>  graph and the intermediate representation, but I don't remember
>  what analyses and transformations are performed on the analyzed
>  code before its CFG is produced. ("soot --dump-cfg" on the other
>  hand, was intended as a debugging tool for soot itself, so it
>  only dumps visualizations of CFGs that Soot produces for itself
>  anyway;  "--dump-cfg ALL" reveals that very few analyses generate
>  block graphs, and those few seem to be baf, rather than jimple,
>  graphs).
>
>  But ... I've just discovered that CFGViewer's ability to produce
>  visualizations of ExceptionalBlockGraphs has been broken by
>  revision 2852 to
>  soot/trunk/src/soot/util/cfgcmd/CFGToDotGraph.java, with the
>  result that my attempt just now to run
>
>   CFGViewer --graph=ExceptionalBlockGraph --ir=jimple CFGEg
>
>  died with
>
>   Exception in thread "main" java.lang.ClassCastException:
>   soot.toolkits.graph.Block cannot be cast to soot.Unit
>         at
>         soot.util.cfgcmd.CFGToDotGraph.drawCFG(CFGToDotGraph.java:345)
>
>  The proximate cause of the failure is that an iterator over the
>  graph's nodes has been changed from an Iterator over Objects to
>  an Iterator<Unit>, but that is part of a larger change which
>  involved tighening the types returned by ExceptionalGraph's
>  methods.
>
>  Eric, from the svn logs it looks like these changes were part of
>  your "genericizing" the dataflow analysis, but it's not clear
>  whether you didn't realize that the ExceptionalGraph classes were
>  intended to provide an interface to Block graphs as well as Unit
>  graphs, or if you decided that there were benefits to restricting
>  the interface to Unit graphs which justified sacrificing the
>  ability to access Block graphs through the ExceptionalGraph
>  interface.
>
>  I'll let somebody explain the intent of the changes before I suggest
>  reverting them :-).  I suppose the Right Thing would be to create
>  some sort of GraphNode interface that both Unit and Block could
>  implement, but my knowledge of soot is far too rusty to judge how
>  feasible such a solution is.
>
>  --
>  John Jorgensen  LCD System Administrator  jorgnsn at lcd.uregina.ca
>                                           306.337.2344
>
>  _______________________________________________
>  Soot-list mailing list
>  Soot-list at sable.mcgill.ca
>  http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>



-- 
Eric Bodden
Sable Research Group
McGill University, Montréal, Canada