Sfink/Static Rooting Analysis: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(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...")
 
(removed 90% of this doc; outdated. Did not update to current status.)
 
Line 1: Line 1:
In response to a request for how to run the rooting analysis locally, for the purpose of implementing a different analysis:
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 a try push (try: -b do -p linux64-haz --upload-xdbs) and just run the rest of it. Everything else is implemented with JS source files from js/src/devtools/rootAnalysis/. The xdb files are enormous uncompressed, but not too horrible compressed.
 
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.

Latest revision as of 20:59, 14 January 2019

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 a try push (try: -b do -p linux64-haz --upload-xdbs) and just run the rest of it. Everything else is implemented with JS source files from js/src/devtools/rootAnalysis/. The xdb files are enormous uncompressed, but not too horrible compressed.