The following is a summary created in 2008 of discussions from that time period about plugin support for GCC. The web page contains various personal points of view. It is not documentation for GCC Plugins and does not describe the licensing policy for GCC Plugins. This page does not describe current, official GCC policy. For official documentation, please see the GCC Internals Manual: Plugins GCC Plugins may use any GPL-compatible license, as described in the documentation about the GCC Plugins API.
This page, being inspired and based on the "Progress on GCC plugins ?" thread on the gcc devel mailing list, is among others dedicated to providing a factually-formalized overview and summary of key issues and -concerns about possibly providing a plugin architecture in gcc, as discussed and identified in the aforementioned thread. A more recent thread is "Defining a common plugin machinery", which is currently (september 2008) ongoing and not yet summarized here http://gcc.gnu.org/ml/gcc/2008-09/msg00456.html.
Please feel free to populate this page with relevant contents.
"So, how do we permit plugins while prohibiting proprietary plugins, and how do we do it while staying within the bounds of copyright law which is the basis of the GPL?"
* most people participating in the related discussions on the gcc mailing list, suggested already that an unstable plugin API would bring all major advantages of plugins in gcc, while complicating the scenario of proprietary plugins. Indeed, it would probably even make sense to consider having a default policy of the plugin API to be modified for each major release, this could be achieved using automated scripts-which would also increase the motivation for plugin authors to keep their plugins in the main repository.
* it was previously suggested (see below for details) to consider the possible advantages of using a scripting interpreter to provide "plugin" functionality in a platform-agnostic fashion (i.e. no DSO support required), depending on whether such an effort would be based on an existing mainstream scripting language (Python, Perl etc) or possibly a custom one, specifically designed and crafted for gcc-use, it would be possibe to pretty tightly couple the corresponding vm/interpreter and its hooks to gcc, so that include files providing the required API bindings to scripts, would be covered by the GPL. By literally "including" such files from scripts, all sources would automatically have to be GPL'ed as well.
* In addition, all such "plugins" would inevitably be in "human-readable" form, so that all plugins can be easily inspected and modified by users and developers. This, would additionally decrease the motivation to spend money on efforts to develop proprietary plugins, given that all source code of the final product would inevitably need to be shared among potential "clients". Even in scenarios where a proprietary plugin might be successful, it should be rather straight forward to provide an enhanced, GPL'ed variant of it due to all source code being readable.
* A gcc-based scripting interpreter could by default check for a mandatory license statement (header) in every source file, so that "stock gcc" could deny running plugins (scripts) with a non-matching license header/marker telling the user that stock gcc only runs plugin scripts covered by the GPL. This in addition would help clarify the licensing situation and would also require potential providers of proprietary, non-GPL'ed plugins to specifically provide a modified/patched gcc version that runs non-GPL modules, thereby removing the major advantage of plugins in the first place: not having to recompile gcc to add new functionality.
* Other open source projects providing support for scripted plugins, only provide a stable API to those plugins that are maintained in the project's own HEAD repository, which might be another incentive for plugin authors, instead of having to keep up with CVS/HEAD manually, i.e. only those plugins that are being officially maintained in the main repository are considered "officially supported", everything else may stop working anytime.
* GCC could come by default with a GPL'ed set of SDK/API files that are required to create gcc plugins, anybody aiming to produce proprietary, non-GPL'ed plugins would have to come up with their own set of SDK files because they cannot use the GPL'ed "gcc SDK".
* In addition, SDK users could -by design- be required to explicitly set up each individual plugin to be covered by the GPL, e.g. by making the proper "init" calls at startup, along the lines of setLicense(GPLv2);
* In order to make it harder for non-GPL'ed plugin SDKs to be used with gcc, stock gcc could by default also require each plugin to provide a certain set of hooks that provide licensing information to the host, so that stock gcc may refuse to run such binaries that do not provide the required information.
* Furthermore, it would be possible to require all plugins to be statically linked with the corresponding plugin SDK (making the plugin itself GPL'ed thereby), thus whenever the checksum/hashes of linked in files doesn't match (the ones of the SDK), gcc could refuse to run any such plugins. Thus, requiring users to also modify the gcc source code to disable the corresponding checks if they want to run plugins created with an inofficial gcc plugin SDK.
* [http://gcc.gnu.org/ml/gcc/2008-09/msg00495.html |"Couldn't the plugin interface require a copyrighted passphrase to be sent by the plugin when it registeres, and the passphrase can then be licensed under the GPL. Thus, plugins that want to interface with an official FSF gcc will have to be GPLed in order to talk to the plugin interface, and we don't need to tinker with the runtime licensing."]
* A copyrighted passphrase, or requiring static linking, sounds a lot like what Lexmark tried to prevent people from cloning its ink cartridges (see Lexmark Int'l v. Static Control Components). Lexmark embedded a program into each cartridge, then had the printer query the cartridge for its program; if it didn't match, the printer wouldn't work. They then sued a cloner for copyright violation, but lost, on the grounds that the copyrighted program was being used strictly as a passphrase.
Introduction
Scope of potential plugin architecture within GCC as is being discussed currently
Advantages of module/plugin architectures in general
- dynamically loaded code can be run in applications that thus don't require recompilation to integrate new functionality
Disadvantages of module/plugin architectures in general
Potential advantages of supporting a plugin architecture in GCC
- "Making it easier to provide additional GCC features"
- "easily getting code to run within a current version of gcc, that would normally never make it into the mainline for various reasons, without having to patch/bootstrap gcc"
Potential disadvantages of supporting a plugin architecture in GCC
"RMS is worried that this will make it too easy to integrate proprietary code directly with GCC."
- "There are some ways in which plugins might make getting proprietary code in the loop easier."
Points in support of a plugin architecture in gcc
* "aren't we already in this situation? There are at least 2 compilers out there that re-use parts of GCC by serializing trees and then reading them into a different back end." * "...proprietary projects can already (without plugins) make exporters for GCC which are GPL and then create the majority of their code in other closed source apps that use that data." * "I don't see plugins as changing this except to make it easier. Which is really a major reason for proving plugins isn't it? Making it easier to provide additional GCC features?"
* "I think it's quite important for gcc's long-term health to permit and even encourage academic researchers and students to use it. And I see plugins as directly supporting that goal. Note that I don't see any problem with requiring (or attempting to require) that any plugin be covered by the GPL."
* "So from my perspective the downside of plugins is very small, and the upside is very large."
* "Typically, researchers are interested in rapid-prototyping to keep the paper mill going. Plug-ins offers a simple method for avoiding the latencies of repeated bootstrap cycles. Several projects will survive the initial prototyping stages and become techniques we can apply in industrial settings. We want to attract that. Plus we want to attract the grad students that did the research and graduate with a favourable attitude towards using GCC in their future career."
* "Plug-ins also facilitate other kinds of work that are not related to optimization passes. Static analysis, refactoring tools, visualization, code navigation, etc. Sean described a variety of different applications they had implemented with their plug-in framework at the last summit. It was all pretty impressive."
* "If you are doing a pass that you are testing and/or prototyping, you don't want to waste time rebuilding the whole compiler. If/when your pass reaches certain maturity, you think it's ready for production, and people think it's a good idea to have it in the compiler, then you convert it into a static pass and you go through the traditional bootstrap process."
* "Similarly, for visualization plug-ins, you don't want/need to bootstrap the compiler. That's the core idea with plug-ins, they allow more flexibility for experimentation. They are not a means for implementing permanent features in the compiler. We would not guarantee ABI nor API stability, there is just no point to doing that."
* "And the sorts of researchers that dnovillo is talking about don't need to do a bootstrap routinely. They are experimenting with new optimizations or with static analysis. They aren't generating actual code. A bootstrap is beside the point."
* "If we make it clear that we consider any plugin to be covered by the GPL, then any attempt to sell a proprietary optimization will face community opposition, thus making even less business sense."
* "And in the end, what will they have? A marginal improvement over the standard compiler. Since they can not hide the results, we can figure out what they are doing and recreate it. In fact, it will be easier for us to do so than it would be for a private port."
Points in support of not implementing a plugin architecture in gcc
Potential Use Cases of supporting modules/plugins in GCC
* I am the maintainer of an open source project called EDoc++. I use GCC to gather data about exceptions and the callgraph of a C/C++ program. This provides the information necessary to perform analysis of C++ exception propagation. I have identified the main issues that have arisen by using a patched GCC in this project that would be solved by using a GCC plugin framework:
Distribution : Packages that distribute a patched GCC are large, may miss platform specific patches that are applied to the base GCC distribution, and can cause conflicts or difficulties in determining where/how best to install the patched GCC.
Usability : Having multiple versions of GCC installed means that users have to perform some "environment configuration" to determine which GCC to use for which tasks, it can confuse users and may also cause conflicts when the two compilers are accidentally mixed.
Maintenance : GCC is actively maintained and new minor versions are released regulary. For a project such as EDoc++ taking advantage of this regular GCC maintenance that is done by others can free me up to develop better "additional" open source projects, rather than taking on the same tasks maintaining the patched GCC in my project that others are already doing for the mainstream GCC. Much of the work i have to do for my project could be eliminated by using a GCC plugin infrastructure.
For example. EDoc++ currently uses GCC 4.0.1 (Yes it is very old) which fails to build on FreeBSD 7. To update my project to use GCC 4.1.0 (for example) I need to modify the build system to check CRC's for the new tarballs and change the patches a little and a few other tasks. What is the real back-breaker is when you start working on the platform specific package maintenance such as creating: dep, rpm, cygwin, pkgsrc packages. If using a GCC plugin framework instead of maintaining my own patched GCC then a lot of this work could be avoided as it is already done by other people. Also my experience is that people are confused about having two versions of GCC installed on their PC. Also my debian package was rejected for inclusion in debian because of the fact that it is "yet another" patched GCC which takes up huge disk space resources. *MANY* of these problems would just disappear with the availability of a GCC plugin framework in the GCC mainline.
Functionality wishlist WRT module/plugin support in GCC
Other opensource projects/efforts directly benefiting from potential module/plugin support in gcc
gcc-xml could be distributed as a plugin for an unhacked GCC
GCC Plugins are currently being deployed at Mozilla to assist with refactoring, having those in mainline would make setting up a development environment much easier.
EDoc++ (Static C++ exception analysis) Could be distributed as a plugin providing easier integration into existing platforms (Debian wont accept another modified GCC package for example).
Technical concerns about supporting binary modules/plugins in GCC
- cross-platform DSOs
Possible ways to address technical issues
- consider embedding a scripting interpreter to provide support for modules/plugins
Legal concerns about supporting binary modules/plugins in GCC
- enforcing licensing (GPL) restrictions
Possible ways to address legal issue
* "[if] no stability in the API [is] offered by GCC to plugins [...] any proprietary plugin would be a nightmare to maintain" * " if we were really clever we could maybe define an interface that's entirely non-enumerable: it calls out to hooks, providing them with just enough information and interfaces to do the job they have to do, but we don't make it possible to derive information about the overall AST because we don't provide any way to know 'what's out there'."
Opensource/-philosophical issues
- possibly not encouraging people to get involved and contribute code back
Possible ways to address opensource/philosophical issues
* don't guarantee a stable plugin/module API
Notable real life cases of Open Source projects supporting the concept of modules or plugins
- Apache
- Mozilla, Firefox
- KDevelop
GPL'ed projects supporting the notion of binary (GPL'ed) modules/plugins
- The Linux Kernel
Related stuff
The MELT branch (MiddleEndLispTranslator) provides a sort of plugin machinery by generating C code (and then .so plugins) at compile time from some Lisp dialect.
The Dehydra-GCC project (at Mozilla) is also plugin based.
MILEPOST GCC - uses Interactive Compilation Interface based on plugins to tune compiler optimization heuristics
This page over at the boost wiki seems to be heavily related to this discussion.
"legal" or license issues
It seems (from GCC summit 2008 steering committee Q&A session) that licensing & legal issues related to plugins are been worked upon.