On 11/20/19, Richard Biener <richard.guent...@gmail.com> 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?). > > 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...].
That might be a good idea for a long-term goal, but I just hope it doesn't get in the way too much of the analyzer getting into GCC in the short-term. The analyzer seems like it could do some really cool analysis, and I'd like to use it sooner rather than later. Rewriting the plugin API sounds like it could take a really long time... > > 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. > > Richard. >
