On Tue, Dec 3, 2019 at 5:52 PM David Malcolm <dmalc...@redhat.com> wrote: > > On Wed, 2019-11-20 at 11:18 +0100, Richard Biener wrote: > > On Tue, Nov 19, 2019 at 11:02 PM David Malcolm <dmalc...@redhat.com> > > wrote: > > > > > The checker is implemented as a GCC plugin. > > > > > > > > > > The patch kit adds support for "in-tree" plugins i.e. GCC > > > > > plugins > > > > > that > > > > > would live in the GCC source tree and be shipped as part of the > > > > > GCC > > > > > tarball, > > > > > with a new: > > > > > --enable-plugins=[LIST OF PLUGIN NAMES] > > > > > configure option, analogous to --enable-languages (the > > > > > Makefile/configure > > > > > machinery for handling in-tree GCC plugins is adapted from how > > > > > we > > > > > support > > > > > frontends). > > > > > > > > I like that. Implementing this as a plugin surely must help to > > > > either > > > > document the GCC plugin interface as powerful/mature for such a > > > > task. Or > > > > make it so, if it isn't yet. ;-) > > > > > > Our plugin "interface" as such is very broad. > > > > Just to sneak in here I don't like exposing our current plugin "non- > > API" > > more. In fact I'd just build the analyzer into GCC with maybe an > > option to disable its build (in case it is very fat?). > > My aim here is to provide a way for distributors to be able to disable > its build - indeed, for now, for it to be disabled by default, > requiring opting-in. > > My reasoning here is that the analyzer is middle-end code, but isn't as > mature as the rest of the middle-end (but I'm working on getting it > more mature). > > I want some way to label the code as a "technology preview", that > people may want to experiment with, but to set expectations that this > is a lot of new code and there will be bugs - but to make it available > to make it easier for adventurous users to try it out. > > I hope that makes sense. > > I went down the "in-tree plugin" path by seeing the analogy with > frontends, but yes, it would probably be simpler to just build it into > GCC, guarded with a configure-time variable. It's many thousand lines > of non-trivial C++ code, and associated selftests and DejaGnu tests. > > Building with --enable-checking=release, and stripping the binaries and > the plugin, I see: > > $ ls -al cc1 cc1plus plugin/analyzer_plugin.so > -rwxrwxr-x. 1 david david 25921600 Dec 3 11:22 cc1 > -rwxrwxr-x. 1 david david 27473568 Dec 3 11:22 cc1plus > -rwxrwxr-x. 1 david david 645256 Dec 3 11:22 > plugin/analyzer_plugin.so > > $ ls -alh cc1 cc1plus plugin/analyzer_plugin.so > -rwxrwxr-x. 1 david david 25M Dec 3 11:22 cc1 > -rwxrwxr-x. 1 david david 27M Dec 3 11:22 cc1plus > -rwxrwxr-x. 1 david david 631K Dec 3 11:22 plugin/analyzer_plugin.so > > so the plugin is about 2.5% of the size of the existing compiler. > > The analysis pass is very time-consuming when enabled via -fanalyzer. > I'm aiming for "x2 compile-time in exchange for finding lots of bugs" > as a tradeoff that users will be happy to make (by supplying > -fanalyzer) - that's faster than comparable static analyzers I've been > playing with. > > > From what I read it seems the analyzer could do with a proper > > plugin API that just exposes introspection - and I really hope > > somebody finds the time to complete (or rewrite...) the > > proposed introspection API that ideally is even cross-compiler > > (proven by implementing said API ontop of both GCC and clang/llvm). > > That way the Analyzer would work with both GCC and clang [and golang > > and rustc...]. > > We've gone back and forth about what a GCC plugin API should look like; > I'm not sure what the objectives are. > > For example, are we hoping to offer some kind of ABI guarantee to > plugins so that we can patch GCC without plugins needing to be rebuilt?
Yes, I think that's desirable. > If so, how strong is the ABI guarantee? For example, do we directly > expose the tree code enums and the gimple code enums? No, we'd remap them semantically. > Or is it more ambitious, and hoping to be cross-compiler, in which case > are these enums themselves hidden? Well, my original idea was to see what people really would use (when just considering introspection and maybe very simple instrumentation). And then sketch something independent of the underlying compiler. And then have that API [or even ABI] implemented by more than one compiler to see if that's viable. > This feels like opening a massive can of worms, and orthogonal to my > goal of giving GCC a static analysis framework. Sure it is orthogonal. The only reason it comes up here is that you propose a "plugin" ;) I'd rather have the current plugin non-API go away so having it "fixed" by introducing in-tree plugins looks backwards to me in that regard. > > So it would be interesting if you could try to sketch the kind of API > > the Analyzer needs? That is, merely the detail on which it inspects > > statements, the CFG and the callgraph. > > FWIW the symbols consumed by the plugin can be seen at: > https://dmalcolm.fedorapeople.org/gcc/2019-11-27/symbols-used.txt > > This is the result of: > eu-readelf -s plugin/analyzer_plugin.so |c++filt|grep UNDEF > > Surveying that, the plugin: > - creates a pass > - views the callgraph and the functions (e.g. ipa_reverse_postorder) > - views CFGs and SSA representation (including statements) > - uses the diagnostic subsystem (which parts of the patch kit extend, > adding e.g. control flow paths), e.g. creating and subclassing > rich_locations, subclassing diagnostic_path and diagnostic_event > - calls into middle-end support functions like > useless_type_conversion_p > - uses GCC types such as bitmap, inchash, wideint > - creates temporary trees > - has selftests > ...etc. Ok. So if one rewrote it from scratch on a hypothetical plugin API then it would need introspection only. But it would need to re-implement a lot of stuff like diagnostics (unless that is easy to expose via a generic compiler plugin API). > But there are inline uses of various functions that don't show up in > that list (e.g. the various gimple_* accessor functions - grepping the > source shows over a hundred uses of these, but they're all inlined and > so don't show up in the above view). > > My gut feeling is that writing a plugin API and then rewriting the > analyzer to use it would be a huge amount of work: I'd strongly prefer > not to do so (and to use the existing API, either as a plugin, or > directly, dropping the plugin machinery from the analyzer). Understood ;) > Perhaps the best way forward is to build this directly into the > compiler, but guard it by a configure-time option? Yeah, that makes most sense. > Dave >
