• GCC_Plugins

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.

Please feel free to populate this page with relevant contents.

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"

*"But, as you say, the whole idea of the GPL is that people can go build what they want -- including plugin frameworks to GCC that might or might not allow them to interface with proprietary code. If it's really worth it to them, then they will. The FSF's best defense is to make it not worth it by providing enough valuable free software."

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."

• It seems very likely that it would be possible to write a plugin which would generate IR to be fed into a proprietary backend. Sun's GCCfss is an existing example of what could be done in this area."

• "There are some ways in which plugins might make getting proprietary code in the loop easier."

• "...people will write trivial marshalling plugins and ship all the data out across a pipe or socket to some proprietary code and then only release source for their shim layers"

• the concern is the many forms of shim layers that possibly could be written more easily with a plug-in framework."

• "There are some ways in which plugins might make getting proprietary code in the loop easier. For example, if omeone plugs Guile into the plugin interface, then it might be easy to write a pile of LISP code to poke at GCC. I understand that there are differing opinions on whether or not these kinds of indirections affect the GPL. But, that's the kind of thing that the FSF gets to think about."

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?"

* "Of course, GCCfss also shows that if people want to do this, they will. Adding a plugin framework doesn't even make it notably easier. Once you've written code to translate GIMPLE into some other IR, dropping it into gcc is a matter of changing a few lines. Providing a plugin interface is not the issue."

* " More deeply, I think his concern is misplaced. I think that gcc has already demonstrated that the only widely used compilers are free software. Proprietary compilers don't keep up over time, outside of niche markets. Hooking proprietary code into gcc, one way or another, is just going to create a dead end for the people who do it. Certainly it's not a good thing, and certainly it would be preferable to prevent it if possible. But it is not the worst possible thing that could happen; it is merely a cost."

* "I won't enumerate the benefits of plugins here. But it is clear to me that the benefits outweigh the costs."

* " Proprietary extensions using a standard plug-in interface will eventually get replaced by free ones if they're of value. In the long term, this type of direct assault on GPL would backfire in a big way."

* "I don't believe this is a strong argument. My contention is, and has always been, that GCC is _already_ trivial to integrate into a proprietary compiler. There is at least one compiler I know that does this. In fact, much/most of the effort we have been spending in making GCC easier to maintain, necessarily translates into a system that is easier to integrate into other code bases."

* "IMO, the benefits we gain in making GCC a more attractive code base, far outweigh the fears of someone co-opting it for their own proprietary uses."

* "We gain nothing by holding infrastructure advances in GCC. While GCC still has the advantage of being widely used, its internal infrastructure is still relatively arcane and hard to deal with. We have already kicked it into the mid 90s, but we still have a lot of ground to cover. An antiquated and arcane infrastructure will only help turn new developers away."

Points in support of not implementing a plugin architecture in gcc

* RMS regularly points to the examples of C++ and Objective-C as an argument for trying to force all extensions to be GPL (Mike Tiemann's employer tried to figure out a way of making g++ proprietary; NeXT tried a "user does the link" hack to get around the GPL for their original Objective-C compiler)."

Potential Use Cases of supporting modules/plugins in GCC

* I'm coming from the verification community and I'm currently very interested in '(automatic) code verification'. What our community is really seeking for by now is a tool aiming at providing an abstract (i.e. simplified) model of program sources. And actually, GCC do it internally. Indeed, you can provide a gimplified CFG of C, C++, Java, ... source files and many other informations, which overpass tools such as CIL (C Intermediate Language, http://manju.cs.berkeley.edu/cil/) because of the numerous front-end of GCC."

Functionality wishlist WRT module/plugin support in GCC

Other opensource projects/efforts directly benefiting from potential module/plugin support in gcc

• llvm-gcc 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.

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

* "how about we define plugins in an interpreted or bytecoded language and don't allow any IO whatsoever?"

Legal concerns about supporting binary modules/plugins in GCC

*Moreover, if we did this in conjunction with a carefully-defined API, the defendant could argue that the purpose of that API was precisely to *not* have it be viewed as a single program, so the result of such a case would be far less certain."

• 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'."

*"I wonder if we could adapt some kind of privsep model, so that once the compiler has finished init, it gives away its rights and can't even open files or create pipes or sockets any more. The gcc.c driver could remain at full user prives and take care of opening everything (a bit like I guess it already does when you're using -pipe?) and cc1 and pals could all be hobbled."

Opensource/-philosophical issues

• possibly not encouraging people to get involved and contribute code back

* "As was pointed out here numerous times, 90+% of the difficulty in working with is the difficulty in understanding the inherently-complex algorithmic structure of the compiler and its data structures (no real-world compiler will ever be able to use algorithms unmodified from a textbook) coupled with limited documentation. Doing something to make the remaining few percent easier will not, in my opinion, increase the participation in GCC enough to justify the legal risk to Free Software."

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.

This page over at the boost wiki seems to be heavily related to this discussion.