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.
