GCC Plugins

There has been recent discussion on the gcc mailing list about plugins. There was a very interesting paper at the last gcc summit about a plugin architecture, with some interesting examples.

I think plugins would be a useful addition to gcc. I think this mainly because many researchers and grad students want it. After many years, gcc is finally getting some traction in the compiler research community. That can only be a good thing for gcc, as it means that more people will learn gcc internals in school and be able to make useful contributions.

Plugins are also useful for people with special needs, like special gcc warnings or the more general case of static analysis. This is code which may not be appropriate for mainline gcc, but is still useful for a subset of the gcc user population.

The people opposed to plugins argue that it will make it too easy to extend gcc in a proprietary way. I think this is a red herring. It is already easy to extend gcc with proprietary code. Plugins will not make that more legal under the GPL, and they won’t make it significantly easier–the hard part is writing the code, not attaching it to gcc.

Plugins do make it easier to distribute those proprietary extensions, but I still think it is a red herring. There are no secrets in the compiler field; it’s not as though anybody can claim some sort of special advantage by keeping their plugin proprietary. And there is no money in the compiler field; nobody can become rich by selling their proprietary plugin, even if that were legal.

The decision as to whether to permit plugins is one about costs and benefits. The costs are low. The benefits are unknown but potentially high. To me the decision is a no-brainer. I’ve been surprised by the opposition I’ve seen on the gcc mailing list.


Posted

in

by

Tags:

Comments

7 responses to “GCC Plugins”

  1. tromey Avatar

    I wish I was surprised by the opposition.

    What benefit does GCC derive from letting RMS have a veto over issues like this? In the current setup, without his assent, there will be no forward motion. Instead we’ll simply discuss the topic every six months, without actually changing anything.

    Today I’m feeling radical and I think that this, plus general SC opacity, means we should fork.

  2. echristo Avatar

    Most of the opposition to gcc plugins are from people who either a) don’t have anything to gain from them, or b) an easier to work on gcc could affect their pocketbook. The ada people are particularly bad here as it is both a and b.

    Getting frustrated for sure.

  3. tromey Avatar

    It occured to me that if we linked gcc with -rdynamic, we could implement plugins using LD_PRELOAD and some glue to insert new passes into the global pass tables.

  4. Ian Lance Taylor Avatar

    I like the LD_PRELOAD idea. Do you think it would fly?

    I think that to the extent to which the SC is a problem, it is fixable. RMS is more of a problem.

  5. Ian Lance Taylor Avatar

    Certainly people opposed to plugins see no gain from them. But many changes see no gain. What we have to overcome is that they see a harm.

  6. tromey Avatar

    I don’t know if -rdynamic would be accepted. I suppose we would have to have a reason for it other than “it enables plugins”. I don’t know of one though.

    The distros could do it, I suppose.

    Or you could change the default in the linker 🙂

    Maybe someone will convince RMS. That is postponing the (in my view inevitable) showdown with him — but postponing that isn’t all bad.

    FWIW, I think the SC isn’t really a problem. If we had elections I would probably vote for the current slate, or at least the visibly active members of it. I liked what I heard from them at the Summit, for instance.

    However, I’m in principle opposed to completely closed decision-making bodies like this one. I think it is bad to have no recourse and no turnover, even if they are doing a good job.

    I do think the SC does too much in private. Perhaps voting or turnover would change that culture a bit. But, there are probably other ways to address it as well.

  7. tromey Avatar

    It took a while but I finally figured out a reason to link with -rdynamic: backtraces.

    According to the libc manual this is needed to get function names from backtrace_symbols. Perhaps we could add backtrace support to the ICE code, and then require -rdynamic as well. This has the added benefit of actually being useful.

Leave a Reply