[cfe-dev] A plugin proposal for clang

[Philip Ashmore]

On 15/10/11 01:31, Joshua Cranmer wrote:
> This is a document in partial response to Douglas Gregor's recent 
> comment about needing someone to push forward a plugin proposal for clang.
>
> What kinds of use cases would people have for a compiler plugin?
>
>     * Add a static analyzer
>     * Production of ancillary metadata for types and declarations
>       (e.g., adding reflective capabilities to C/C++)
>     * Custom optimization passes
>
* anything we haven't thought of yet
>
> The current architecture appears to assume that clang plugins and 
> clang itself are primarily useful for static analysis and not for 
> production. If I wish to use a plugin, I have to use:
> clang -cc1 -load /path/to/plugin.so -plugin Foo -plugin-arg-Foo Bar
>
> But if I'm trying to drop in this plugin in a regular build, I need to do:
> clang -Xclang -load -Xclang /path/to/plugin.so -Xclang -add-plugin 
> -Xclang Foo -Xclang -plugin-arg-Foo -Xclang Bar
>
> By comparison, a gcc plugin lets me do:
> gcc   -fplugin=/path/to/plugin.so -fplugin-arg-plugin-bar=baz
>
> The key things that gcc lets me do in a plugin that I think are 
> necessary for clang are to be able to define custom attributes and 
> pragmas, which are largely necessary for custom static analysis 
> scripts: for example, Mozilla defines several attributes to allow 
> checking of properties in their gcc plugins (e.g., enforcing 
> outparameter guidelines). All of its other features appear to be 
> either an artifact of its code design (e.g., GC interactions) or 
> features that are already supported (e.g., adding a new optimization 
> pass).
>
> Another thing which I think is necessary is a macro for the version of 
> clang being built, so that plugins can support multiple versions of 
> clang at the compiler level (supporting multiple versions in binary 
> form is inadvisable, I think).
That wouldn't help with future versions.
>
> With that background, here is my rough proposal for plugins; there are 
> other changes that I think many plugin writers might like to see, but 
> I'll hold off on them, since they don't inhibit writing useful plugins:
> 1. Add in -fplugin= and -fplugin-arg-<plugin> options for the compiler 
> driver. All of the plugins in the library would be loaded and run as 
> if specified with -add-plugin (in other words, clang still compiles 
> the code).
> 2. Add examples of plugins that illustrate iterating over the AST and 
> getting IR for functions for futher passes.
> 3. Ensure existence of support in clang for custom attributes.
> 4. No guaranteed of API or ABI compatibility between different 
> versions of clang; the onus is on the plugin to figure out how to 
> support multiple versions. Note that this implies that a version macro 
> is needed to report the version of clang/llvm that the plugin is being 
> compiled for.
Thus offloading responsibility from one central point (clang) to N 
plugin developers with varying levels of ability.
This doesn't consider the possibility that one plugin might require 
another plugin / interface implementation, or that there could be 
"standard" plugins as part of clang.

It sounds a lot like apache modules, but without the configuration file.

Instead I'd recommend an interface based approach, like COM.
The compiler driver looks up a registry when it needs to create anything,
and gets a factory object from which it creates instances.

Even control of what steps are performed by an object constructed from
a factory obtained from the registry.

This could allow control of what the compiler does, even without adding
other components.
>
>
> Thoughts/questions/comments/concerns?
> -- 
> Joshua Cranmer
> News submodule owner
> DXR coauthor
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Also, instead of supplying a long list of plugins with their arguments, you
could use a sandbox - a registry in a file, to which plugins are registered,
and checked for conflicting roles at registration time.

Then you just provide the name of the registry sandbox file to the compiler,
and off it goes.

You can check out

    http://sourceforge.net/projects/v3c-dcom/

for examples and a sandbox implementation.

Last but not least, plugins could support different clang versions by
implementing more than one interface.

Philip