Re: gcc project

[Diego Novillo <dnovillo at redhat dot com>]

On 03/27/06 16:35, Nic Volanschi wrote:

> The checks are specified using a new option --tree-check, and are
> powerful enough to express user-defined memory leaks, null pointer
> dereferences, unreleased locks, etc., but also more basic checks such
> as using an unsafe construct.
> 
Oh, excellent.  Coincidentally, we have been thinking about developing
some kind of plugin/extension framework to allow these classes of
analyses.  One of the goals is to provide an extensibility mechanism
that will not require rebuilding GCC nor adding code that may not be
often used.  Some of these checks are only interesting in very specific
cases, so they may not be something that we want to add to the compiler
itself.

So, the idea is to have a generic .so plugin mechanism with a relatively
stable API that lets you hook into the compilation pipeline and do your
analysis/transformation.  This would have the double advantage of
allowing people to write ad-hoc passes and/or analyses that may not be
suitable for the core compiler.  It would also allow users to extend GCC
without having to get into the source code itself (assuming we get the
abstractions and exports right, of course).

I have not thought too much about this beyond these obvious
generalities.  While I believe that we have most of the abstractions
that we would want to export (CFG, iterators, operand interface, SSA and
IL discovery mechanisms), I am particularly concerned about our ability
to maintain a stable enough API across multiple versions of the
compiler.  We do tend to make lots of arbitrary internal changes that
may shatter the API.

I'd be very interested in taking a look at what you've done.  Perhaps
the best approach for you now is to get this code into a branch.  We
already are in a "no new features" stage for 4.2.