Sfink/Static Rooting Analysis

Revision as of 18:05, 8 October 2013 by Sfink (talk | contribs) (Created page with "In response to a request for how to run the rooting analysis locally, for the purpose of implementing a different analysis: One thing that might help is that I have jobs runn...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

In response to a request for how to run the rooting analysis locally, for the purpose of implementing a different analysis:

One thing that might help is that I have jobs running on tbpl now. If you push with -p linux64-sh-haz,linux64-br-haz you will get builds for the JS shell and the full browser. Except that the browser one will fail due to bug 923374.

Those aren't likely to help you much, but to implement those, I moved all of the logic for running the builds into mozharness. So in theory, if you have a linux machine, you can do something like

 % hg clone http://hg.mozilla.org/build/mozharness
 % cd mozharness/scripts
 % $EDITOR ../configs/users/sfink/spidermonkey.py # Update to local values
 % python spidermonkey_build.py -c users/sfink/spidermonkey.py -c hazards/common.py -c hazards/common/build_browser.py --no-setup-mock

and it'll try to do everything. Where "everything" is "way more than you want" -- it'll do a full checkout and things. If you point it to the right things in spidermonkey.py, you can use an existing checkout. Then I'd say do the same command as above but without the --no-setup-mock, and instead do each of these in turn (note that --list will give all the possible actions):

 <...> --configure-shell --build-shell
 <...> --setup-analysis
 <...> --run-analysis

If you don't like going through so many layers, you really need:

1. Build sixgill

2. Build an opt shell with ctypes enabled

3. In js/src/devtools/rootAnalysis, edit defaults.py to point to your various checkouts. Here's mine:

 js = '/home/sfink/src/MI-GC/obj-opt-js/js'
 analysis_scriptdir = '/home/sfink/src/MI-GC/js/src/devtools/rootAnalysis'
 objdir = '/home/sfink/src/MI-upstream/obj-analyzed'
 sixgill = '/home/sfink/src/sixgill'
 jobs = 2

objdir is the object directory that you'll be compiling into (the first step of the analysis is to compile the full tree with the sixgill plugin enabled.)

4. Make some work directory somewhere to hold the analysis intermediate files and output. Cd to it.

5. python $SOMEWHERE/js/src/devtools/rootAnalysis/analyze.py

analyze.py is another job runner script. You can use --list to show the different jobs. If you've managed to get the tree built and have the *.xdb files lying around, then you can rerun just the analysis by doing

 python $SOMEWHERE/js/src/devtools/rootAnalysis/analyze.py callgraph

A "job name" at the command line will *start* at that job and it and everything that depends on it. If you want to run one step in isolation, you can do something like

 python $SOMEWHERE/js/src/devtools/rootAnalysis/analyze.py callgraph --upto callgraph

In fact... come to think of it, if you want to implement a new analysis, then probably the easiest way is to skip all of the nasty hairy bits of compiling the tree with the plugin installed, and instead copy over some .xdb files from me and just run the rest of it. Everything else is implemented with JS source files from that rootAnalysis directory. Let me know if you want to do that, and I'll post them somewhere. (They're enormous uncompressed, but not too horrible compressed.)

sixgill itself is not always that nice to compile, though I've landed several patches to make it better. If you have the .xdb's, you can skip sixgill entirely.