Plug-In Architecture On the Way For GCC

VonGuard writes "This year marks the 25th anniversary of the GNU Operating System. A major part of that system has always been the GNU Compiler Collection. This year, some of the earliest bits of GCC also turn 25, and yet some of the collection's most interesting years of growth may still be ahead. The GCC team announced today that the long-standing discussion over how to allow plug-ins to be written for GCC has been settled. The FSF and the GCC team have decided to apply the GPL to plug-ins. That means all that's left is to build a framework for plug-ins; no small task to be sure. But building this framework should make it easier for people to contribute to the GCC project, and some universities are already working on building windows into the compilation process, with the intent of releasing plug-ins."

Comments

So why do I want plugins in my complier?

[NobleSavage]

Can someone explain what kind of plugins might be made? What extra functionality wold I want in a compiler?

Re:So why do I want plugins in my complier?

[Anonymous Coward]

Can someone explain what kind of plugins might be made? What extra functionality wold I want in a compiler?

Static analysis.

Re:So why do I want plugins in my complier?

[Anonymous Coward]

And there are tons more use cases than that! My research group has a complete plugin system already implemented for GCC, and I've written a few plugins for it.

I've got plugins that put hooks in for all sorts of variable access, function call and lock events so I can put in custom debugging code. My current project involves collecting statistics and detailed logs for these events in the Linux kernel.

Because the compiler knows so much data-flow and type information, we also think that these plugins could be perfect for sophisticated static analyses.

Also, it's funny that another poster suggested trippy visualizations, since one of the projects in the group just so happens to be a visualization! It's not the trippy kind though. Actually, it shows you control flow graphs after compilation and lets you drill down into the compiled representation (a 3-address code known as GIMPLE). It's designed as a tool to aid in debugging new plugins, but it may also be useful for people who want to learn about compilers or people trying to figure out how to write code that optimizes better.

Check out the paper:
http://www.fsl.cs.sunysb.edu/docs/gccplugins-gccsummit2007/index.html

GPL to plugins?

[jpmorgan]

Does this mean they want to force all plugins to use the GPL? How is that possible? I was under the impression that the GPL is purely a distribution license. It comes into force when you distribute software licensed under it, and requires you to distribute (or make available) source code and other things.

If I write a plugin and do not distribute it with GCC, what legal basis do they have to force me to GPL it? Nothing I distribute is copyrighted by the FSF, and so how can their distribution license apply to my code? I'm confused.

Re:GPL to plugins?

[againjj]

More precisely, the exception states that if the end compiled product is built with non-GPL compatible plugins, then the end compiled product is subject to the licenses of the linked libraries using the exception. As at least some of those linked libraries are subject to the GPL (being part of GCC) then the end product will be subject to the GPL. If you want to propagate (distribute) the end compiled product, it needs to be a GPL-compatible program, which then means that any libraries linked with it need to be GPL-compatible too, which prevents proprietary libraries linked in. If you do not propagate the end compiled product, then no problem.

So, long story short, if you have a non-GPL plugin, then either (1) the plugin must be GPL-compatible, (2) the plugin can't affect the end compiled product, or (3) the compiled program must be GPL-compatible and not be linked with anything non-GPL-compatible (say, a proprietary plugin). Basically, they want to prevent plugin writers the ability to lock down a GPL program by requiring that it be compiled with the proprietary plugin. I think there is a loophole in (3), so I hope I did not misunderstand it.

Re:GPL to plugins?

[Bruce Perens]

This is really bad advice. If your plugin is not distributed with the GPL software, it's still a derived work.

Re:GPL to plugins?

[QuantumG]

Sorry for the multiple replies.

Friend of mine once pointed out that practically the whole "let's GPL the library so any apps that use it have to be GPL too" strategy has been thoroughly dismantled by the BSD community.

Consider libedit. It's a BSD-like licensed replacement for libreadline - RMS's favorite example of "strategic" non-use of the LGPL. It's binary compatible with libreadline. So you can create your app and link it to libedit and happily distribute it under the BSD. To claim that libedit is somehow a derived work of libreadline because it has the same binary interface would be absurd. However, many installation scripts make a symbolic link from /usr/lib/libedit -> /usr/lib/libreadline.

That's the strong case for dynamic linking == derivative work.. plugin frameworks have always been the weak case. If the strong case doesn't stand up anymore, how can the weak case?

Don't get me wrong, I don't want to see proprietary plugins for GCC anymore than I like seeing all the proprietary modules for the Linux kernel. But claiming there is some clear legal principle that makes them a copyright violation is a joke.

Re:GPL to plugins?

[QuantumG]

define "bad". RMS thinks proprietary plugins would be bad because he thinks everything proprietary is bad.

But let me give you an example. I once worked at a company called Codeplay in the UK. They made compilers, proprietary compilers, and one of their biggest markets was the Playstation 2. Everyone used GCC to develop on the PS2. Ok, a few people used Metroworks' compiler - whatever. So they were directly competing with GCC. Our C++ support was horrid. Our C support was better, but one of the things I did was write automated testing tools that compiled "random" C programs with GCC and out compiler and compared the warning/error messages and output from running the program if it actually managed to compile. Anyway, some of the guys there had written instruction schedulers for GCC that made the code generated by GCC for the PS2 actually half decent. This code never saw the light of day because it would have competed with Codeplay's offering. If GCC had a plugin framework (and wasn't so nazi about proprietary extensions) we would have completely changed our business model. Our customers most certainly would have preferred it.

Re:GPL to plugins?

[AxelTorvalds]

I don't know that it has been fully established in court, my company's lawyers are scared enough by all of the language though. The intent is pretty clear, if you use GPLed code in some capacity of leverage it, they want you to GPL your code too. That's always been the idea. In the case of a compiler plugin, depending on how it is linked and other things, if you distribute it at all, you might need to make your code GPL compliant. GPL3 tried to make that all more clear and GCC is GPL3.

I'm not going to push the ideology here but the last decode or so has shown in more than a few cases the only time this seems to matter is when some company doesn't have the resources to build something but they want to put some tweak on it and sell that. If you're writing some kind of optimizer that you need to keep "secret" but you can't build a full compiler then it's hard to offer much sympathy. If you're building some sort of static analyzer or something that you need to keep "secret" again, I think there are more than enough holes here, you really just can't link to GCC, write your plugin, GPL it and just have it dump whatever intermediate form you need. Custom language or custom hardware support? There are probably some more treacherous areas, I'd imagine that some of the better ILs are somehow protected, and I'd also imagine more than a few compiler jocks would like to graft some of that stuff together, you know GCC's parser and Yoyodyne Corps optimizer and code generator, stuff like that.

Having worked with more than one chip vendor that "sold" a GCC derivative that supported their hardware, to be completely honest it would have helped our cause and theirs to just GPL the code to begin with.

Everyone thinks compiler plugins is cool for one reason or another and just about everyone will hate it when there is some interesting plugin that costs $2500 a seat and does some cool stuff but in only runs on Redhat's enterprise Linux in 32bit mode... with a version of GCC that is 2 revs back.

Re:GPL to plugins?

[Bruce Perens]

SCO wasn't an API case. Long before the SCO case was brought, that API was a US Government standard.

It's not just that the API is duplicated, it is that the duplicate is made to be dynamic linked to the main work. The closest thing we have had to a dynamic linking case was Nintendo v. Goloob Games. That was about the Game Genie plugging between the Nintendo console and the game cartridge. It's not entirely germane to what we're talking about here. Over the 20 years we've been talking about dynamic linking, there's still been no case law.

Re:GPL to plugins?

[Bruce Perens]

It's a system that is there to differentiate between purposely exported symbols for interoperability, and internals which are not providing an interface for interoperability. The fraud comes when a program that doesn't really have the the legal permission to use the internals provides a lie to do so. There isn't anything restricting the provision of a GPL device driver which would be fully compatible and interoperable except some internal intellectual property restriction of the organization providing the driver. So, who is on the side of interoperability here? The party that hides its driver internals and lies about its license, or the party that asks third parties to give rights to others.

Re:It's Linux, NOT GNU/Linux!!

[CannonballHead]

I am aghast. Please use proper capitalization of "GNU." Your lack of respect for the roots of your operating system is disgusts me.

:P Seriously, I read the GNU website stuff (some of it) and ... ok, I get the point, but it's almost like they're on an ego trip, whining about how people are giving them proper credit, and wanting everyone to know how important they are. Frankly, I don't honestly care that much about Linus. And why not give credit to people who created Unix, since it's hard to write an OS that isn't influenced by current OS's?

Meh. If "Free Software" and "Open Source" and "GNU/Linux" means that sort of elite "you need to remember your roots and never use non-free software no matter how much it costs you or anyone else! Refuse to make money using any non-free software! And don't forget who we are!" attitude... well, even Microsoft doesn't seem that bad :) And I LIKE free software. And donations. And Magnatune. And dislike Apple. And iTunes... [continue list of Slashdot Qualifications]

25 years of ....

[fm6]

This year marks the 25th anniversary of the GNU Operating System.

No, this year marks the 25th year of work on the GNU OS. There is still no GNU OS as such, and it's pretty obvious there never will be.

I'm not saying that there's nothing to show for all that work. The GNU libraries and many GNU utilities are key components in many projects, not the least of which is Linux. (<Sarcasm> Oh, excuse me, GNU/Linux.</Sarcasm> ) These are real achievements, and so is the introduction of a new collaborative model of joint software development.

But the original goal of GNU, to create a free alternative to Unix, has never been achieved. No big loss, there are other free Unix alternatives and even true Unixes for free. I just wish that GNU and its fanboys would stop and ask themselves why they never achieved their primary goal.

Re:25 years of ....

[Creepy Crawler]

That's because it takes thousands of people to make an OS.

Look at Microsoft and their lines of OSes.. They have what, 50k people on staff at any one time with perhaps 2/3 of them doing programming work? Most of their code is already written from buy-oughts, so they now provide mostly maintenance and scripting. There's maybe 20-50 people doing *interesting* stuff at any one time, it being 10 years away.

Look at OSX now. They have a similar issue, but leveraged theirs away by choosing a FreeBSD-like platform which to design everything on top of. They also reduce features for their core GUI programs to reduce testing and errors. They also focus much more aesthetically, in direct comparison to Linux GUIS and Windows. And their equipment is much higher priced (can buy 2-3 laptops of the same quality of 1 mac laptop), considering they discourage Hackintoshes.

The Linux guys ad to design everything from the ground up, because of the choice in license. It was also a NiH kind of "I can do it better" kind of game, because Linux was new and exciting. But development still requires large resources. Linus happened to be the appropriate coder/manager to herd the cats at the bottom. Then everything else fell into place: some by luck and others by necessity.

FreeBSD: Its THE academic system, and it works well. It's a traditional fork from SYS I which they license it very openly. There's work done on it, but the "cool" work is Linux. The BSD's are perfect for stability, file sharing, and network code. It has a healthy set of adherents and users, but mostly is relegated to core network technologies.

Now, we look at HURD.. It's there, with a Debian/HURD system install possible. It's there's few device drivers, even fewer developers, doesnt work with basic equipment, buggy as hell (because few developers), and there's something that's "Just As Free", and works to boot (Linux). Would the FSF be better off on discontinuing the HURD? Probably, but it's their choice, and we dont know what its possible uses are yet either.. There's always a critical mass which things like these hit that make them explode, and they might be right about making their own kernel.

Nothing More Than GNU/Panic Over LLVM/Clang

[Anonymous Coward]

All the exciting complier action going on now is with LLVM and Clang. It's incredibly clean and modern code. It has an free and open non-viral license.

The GNU crowd sees it as a massive threat to the stranglehold GCC has over open source compilers. This is nothing but a desperation move by GCC to try to fend off the massive migration to LLVM that is going on. The GNU crowd has been acting in ways that would put Microsoft to shame in their efforts to keep their stranglehold on compliers. All the way from the way GCC is coded to anonymous trolling of everything they see as a threat to non-GPL complier tech.

LLVM is going to be the one of and perhaps the single most important thing in the history of compliers. The academic world, business world, hardware manufactures are migrating to LLVM.

Re:It's Linux, NOT GNU/Linux!!

[wild_quinine]

why do people still try to attach GNU/ to Linux?

Ah, the great Gnu/Linux naming controversy. It's a long page for a short issue, but if you really want to kill a tree, try printing the talk page, instead.

You know that there's zealotry involved when the argument for justification of a single sentence is longer than the entire article.

Re:It's Linux, NOT GNU/Linux!!

[hobbit]

There are two stories here:

1) 25th anniversary of GNU OS project
2) GCC plugin approach agreed

They coincide, and both relate to the FSF, so why shouldn't they be brought together in a single article?

Re:That means all that's left is to build a framew

[TheRaven64]

Or just do what the rest of us are doing, and hack on LLVM. It's BSDL, so you can license your plugins however you want, and it's very modular so it's easy to reuse parts of it. Oh, and it's actively backed by Apple, Adobe, Sun, Cray, and a few others including a number of universities.

It's GNU/Linux if it's not uClinux

[tepples]

but trying to run an open source based box without any of the software that gnu has touched is pretty hard

I for one say "GNU/Linux" to distinguish an operating environment designed for a workstation or server from embedded Linux. It's possible to run a useful box, especially one handling embedded style workloads such as IP packet routing, with very little FSF-owned code. A "uClinux" environment might use uClibc or Newlib instead of glibc, uClibc++ instead of GNU libstdc++, and BusyBox instead of Bash and GNU Coreutils.

Nice

[coryking]

Mod me as a troll if you must but... People ought to read the link given by the parent. Wow.

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

Nice. You know, in a very funny way, the FSF and their jiahad against the evils of proprietary software are basically creating their own twisted form of DRM. Witness this brilliant idea:

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

Nice. The Linux kernel guys did this and look at the result--it is a bitch for hardware guys to write drivers for Linux. I'm sure deliberately altering the API with a script will work really well for the GCC guys! Makes me want to participate. Not! In truth, it makes me feel like I'm some kind of criminal--only guilty until proven innocent.

Sadly, the FSF did some very nice things, but I think they are becoming so extreme they are going to marginalize themselves and fade away. You know what the biggest hurdle for the BSD guys go separate themselve from GPL? The compiler. The compiler really is the last bit of power the FSF holds over the open source world as a whole. Pretty much every other bit of the toolchain has been replaced with a non-GPL lisence except a good compiler.

LLVM seems to be coming along nicely with major players backing it. I'd be pretty nervous if I was the FSF.

Re:How spell check could work in a C compiler

[Schraegstrichpunkt]

"Referer"