On Wed 06 Mar 2013 09:34:28 AM PST, Joshua Cranmer 🐧 wrote: > On 3/6/2013 11:26 AM, Gregory Szorc wrote: >> >> Bugs 733873 and 767563 (possibly dupes) are open to track >> implementing a Clang plugin to perform analysis of our source and >> builds. All we need is a hero or two to get an initial version >> committed. We can iterate on what it does later. > > I have a working static analysis plugin that reimplements the > NS_STACK_CLASS and NS_MUST_OVERRIDE checks from the days of dehydra > (and I can also finger cases where the build would fail). The reason I > haven't pushed harder on checking it into the tree is because it > doesn't work properly on OS X due to linker visibility issues (the
The SpiderMonkey GC (garbage collection) team currently relies on a static analysis to identify rooting hazards. It uses Brian Hackett's sixgill system <http://sixgill.org/>, which uses a gcc plugin to extract information during compilation. It depends on at least gcc version 4.7, but it works with a full browser build with a slowdown of around 2x (maybe a bit less; I don't have a good baseline.) That's just for the extraction phase; the full analysis takes much longer and is currently running out of memory (for a silly reason; it shouldn't be hard to fix.) But that part can be done in any of a number of ways, and the speed depends largely on the analysis you're doing. (AIUI, the sixgill system has a framework for implementing specific analyses too, which we're mostly or entirely not using. I believe those analyses are much faster and can use external solvers.) > Without tinderbox builds that would turn the tree orange or red on > failure, there's no point checking this support into the tree. I intend to land the harness & analysis portion of our analysis into the tree Real Soon Now, but not the plugin itself. I'm adding a --with-sixgill=... configure flag for that. But that's just to make it easier for people to find and run the code; it doesn't integrate with our build system or anything. And it's not really practical for a full-browser buildbot slave run (though simpler analyses would be, if we were willing to install an additional gcc 4.7 package on the mock slaves.) I am currently running the analysis every hour on my own server for just the Spidermonkey subtree. It takes 36 minutes for the full build + analysis, and generates a report file that people download to read through. It also feeds into an irc bot (say hi to mrgiggles on #jsapi! Or 'help', rather.) I would guess that once we resolve the issues with the full-browser analysis, it'll take 5-6 hours in total. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
