Joern Rennecke wrote: > The main utility of plugins is that they make developing, testing and > deploying modifications to gcc easier.
This may be true now, but I certainly hope it will not be true in future. I view the current plug-in mechanism as a prototype. I think that we should be working toward a much more robust mechanism, similar to plug-ins for Eclipse, Firefox, MySQL, or other popular software stacks. I certainly see no reason that plug-ins cannot work on any system that has something roughly equivalent to dlopen (which Windows and OS X certainly do). There's lots of prior art here. The key change we need to make is that instead of the current "unstructured" approach where we essentially expose the entirety of the GCC internals, we provide a stable, documented API that exposes a portion of the internals. (It's fine with me if there's an expert mode in which you can do anything you want, but it should be easy to stay within the stable API if you want to do that.) I would start with an API for "observing" (rather than modifying) the internal representation, and add modification later. With observation alone, you could start to build interesting static-checking tools, including, for example, domain-specific tools that could check requirements of the Linux kernel. This would be a powerful and exciting feature to have in GCC. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
