On Thu, Mar 29, 2012 at 2:34 PM, Niels Möller <ni...@lysator.liu.se> wrote: > I originally wrote this email as a reply to Ian Lance Taylor on a > different list, and he suggested that I send it also to the gcc list. > Please cc me on replies, since I'm not subscribed to the list. I hope > I'm not being too off-topic or off-the-mark. > > Let me write down some reflections on gcc extensibility, even if I'm not > familiar at all with gcc internals. > > 1. I imagine the plugin API ought to stay in plain C, right? > > 2. Then there are at least two ways to think about the plugin API to, > e.g., the gcc tree abstraction. > > Either one can define a C API one think the plugins will like, and > then implement that on top of the internal C++ interfaces. These will > be small wrapper functions, which lets the internal interfaces evolve > without affecting the plugins. > > Or one sticks to a single "unified" tree API, to be used *both* > internally and by plugins. > > I suspect the second option is the right one, because it brings some > equality between plugin authors and gcc developers. It should make it > easier to adopt a plugin into gcc proper. Together with (1), this > forces the internal interface to be C rather than C++, which I guess > you may see as a serious disadvantage.
On the contrary - I think the first option is the right one. Only that way we can provide a stable ABI towards plugins. > Going for a unified API, one gets less independence between plugins > and gcc internals, but in return, one gets less clutter, and I think > it may improve quality. Otherwise, it seems likely that one ends up > with an internal interface which is powerful but somewhat ugly > (internal use only, right?) and an external interface which may be > beautiful on the surface, but in practice it's a second class citizen > and awkward for doing interesting things with. It really depends on what plugins should be doing. Or rather what most plugins will end up doing. In the end we probably will end up with a stable plugin API/ABI for that common case (introspection and simple instrumentation) and the awkward current one exporting every GCC internal. > 3. What is the purpose of the plugin API? I can see that it should make > it easier to prototype new optimization passes. Both for educational > purposes, and research, as well as by the gcc developers themselves. No. That's way easier to do if you are _not_ a plugin. > One of the goals you stated was "I think parts of GCC needs to move > toward being a component of tools other than pure compilation, such > as refactoring, profile analysis, debugging." Right, and I see primarily those uses. Richard. > I think we can all agree that's highly desirable. To be more > concrete, I think it would be useful have access to information from > the parse tree, from the symbol table (both for compiler and linker), > dataflow analysis, etc, when editing C code in emacs. Is a plugin API > the right tool for that type of integration? Or should one also have > a gcc library, and have various other specialized tools link to that > library? > > Maybe the organization of valgrind could provide some inspiration, > with a couple of different tools on top of the same machinery. > > Happy hacking, > /Niels > > -- > Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. > Internet email is subject to wholesale government surveillance. >
