CFG and body dumping options (Was: About revision 1407)

[John Jorgensen <jorgnsn@lcd.uregina.ca>]

>>>>> "vranganath" == Venkatesh Prasad Ranganath <vranganath@cox.net> writes:

    vranganath> Hi, I am using revision 1407.

    vranganath> ExceptionalUnitGraph has a DEBUG flag that causes
    vranganath> humongous exception dumps. It would be much
    vranganath> simpler and convenient for the users if Soot
    vranganath> embraced a logging framework.  Just a suggestion.

I actually don't know enough about logging frameworks to make an
informed response to your suggestion, but I feel an obligation to
say something about the motivation for these dumps, since I'm their
perpetrator.  And not only are they humongous, they also create
ugly filenames that include spaces and punctuation marks.

Since we will have to decide whether to leave this dump option in
place for the next release, I'm going to take advantage of your
question to bring the option's existence to the notice of other
Soot developers, though that will involve explaining some things
that you, Venkatesh, have already figured out for yourself.

The dumps occur if you specify some value for soot's new

  --dump-cfg <phase>

option, which says to dump dot-file representations of all the
CFGs produced during the phase named <phase>.  Or you can say

  --dump-cfg ALL

and get a dot file for every single CFG that soot produces.

--dump-cfg has a companion option which actually predates it:

  --dump-body <phase>

that says dump a representation of the intermediate
representation of each method body before and after <phase>, or
before and after each phase, if you specify

  --dump-body ALL

The origins of --dump-body go back to last spring, when we were
updating the documentation for Soot's command line options.
Since we had to reverse engineer the meaning of some phase options
which predated any of the current Soot maintainers, I wanted the
ability to compare the input to and output from each phase when
various phase options were specified.  I found being able to see
Soot's representation of a method at arbitrary points very
useful. 

Since then, I've been involved a couple of times in trying to
diagnose errors that users have encountered when they ran Soot on
their own classes or on classes from third-party libraries to
which I do not have ready access.  I imagined that would have
been easier if I could have said "Run soot with '--dump-body all'
and send us the last jimple file produced before soot throws an
exception."  So I'm inclined to argue that we should not disable
--dump-body in the release.

--dump-cfg, unlike --dump-body,  might be of little use to people
who are not modifying the CFG classes (i.e. people other than
me).  I included it because I needed to examine the CFGs produced at
intermediate stages in Soot's processing of each method, rather
than just at the end after all transformations are complete.

You don't get the humongous output unless you specify --dump-cfg
and/or --dump-body options on the Soot command line (these are
documented; run "generate-tutorial" in the tutorial subdirectory
of your soot working directory, and look at
usage.{dvi,ps,pdf,html}). So I confess that I don't see why this
is major issue. I'm reminded of a very old joke: The doctor
raises his hands above his head and asks his patient, "Does it
hurt when you do this?" The patient tries and groans with pain,
"Yes, it does!"  The doctor replies, "Then don't do that."

Nevertheless, if you feel that the dumping options are likely to
cause more harm than good in their current form, I'd be glad to
hear why.  Presumably your suggested logging framework would
provide more fine-grained control over what gets recorded.  That
would certainly be a good idea, but I'm not sure who would be
interested in implementing it.

I have, though, removed some of the chatter from the graph
dumping code (it used to throw and immediately catch an
artificial exception to manufacture a stack trace if a graph
was constructed while no identifiable phase was running).  I'll
wait for feedback on the next paragraph before committing that
change.

Now for a point that will only be of interest to current Soot
maintainers. Currently the dumping code is conditional on DEBUG
flags in the CFG constructors, soot.Pack, and soot.Transform.
Since I added documentation describing the dumping code to
soot_options.xml, the DEBUG flags are probably a mistake: options
documented for users should not be conditional on DEBUG options.
So we should either make the dumping options official and remove
the DEBUG flags, or remove the user-visible documentation. I have
no strong preference, and will follow the consensus.