Live data from Hacker News

Extracting the abstract syntax tree from GCC

lwn.net

21–30 of 112 posts

Re: Extracting the abstract syntax tree from GCC

#21
post #12

Earlier quoted context omitted.

The issue is not that the plugin wouldn't be gpl; it would. The concern is that the AST dumped is not code, but an artifact, and thus can be used by proprietary software and make proprietary software better. I could write a program that compiles your gcc-produced AST for a new architecture, and not GPL it because the AST itself probably isn't GPL protected. That's the fear.

The fear that someone else might be "better" than you so you're intentionally going to make it impossible for them to even compete is a really dumb argument. Imagine if this was done in sports. And that seems to have been the whole intention behind this. Make sure no non-GPL backend can be used because god forbid it's better than ours. The shame!

> The fear that someone else might be "better" than you so you're intentionally going to make it impossible for them to even compete is a really dumb argument. Imagine if this was done in sports.

It is done in sports. Most sports forbid you from taking drugs that enhance your performance, or are seggregated by sex in order to account for the "natural" (?) unequal distribution of muscular mass across sexes, because we think these would be unfair advantages.

The idea here is that the big proprietary software companies are not playing on a level field, since they are not disclosing their source code. The GPL, as I understand rms's intentions, is designed to inhibit that advantage and force everyone to play fairly: if you take code, you must give back code.

I don't understand much about the particulars of this case, and public opinion seems to be heavily slanted against rms. Nobody seems to agree with him here, but he's been considered a fool in the past when he was more of a Cassandra. His positions usually come from past experiences he's had.

Someone else mentioned elsewhere in this thread that historically the fear was of Intel using gcc as a frontend for icc. Seeing how Intel still contributes code to gcc and how they still maintain icc and how they still love publishing non-free software, perhaps this is still a valid fear. Or perhaps everyone is just using LLVM already for this purpose and it's not likely they would use gcc instead. I don't know.

I don't want to cast an opinion on this case beyond what I've already said. Maybe rms is wrong or maybe he's right.

Re: Extracting the abstract syntax tree from GCC

#22
post #17

Earlier quoted context omitted.

GCC has multiple, rich ASTs that you can access by modifying (and freely distributing) the source, or you can build a plugin that access the AST through the API. The debate hinges on a very subtle point: GCC does not commit to keeping the plugin API nor the AST structure stable between releases, making it difficult to maintain any software that relies on a specific shape of the plugin API or the ASTs.

And the absolute certainty that without getting buy-in from RMS, the API would be constantly changed to frustrate such a AST dumping API. Unless GCC and/or EMACS (using LLVM) gets forked. Again.

True, but it takes effort to change the API, and even if they did something obfuscatory to it automatically with every new version, it wouldn't be all that hard to write something that parses GCC's source code or compiles programs specifically designed to exercise the right paths - and grabs the right bits automatically; a meta-AST-extractor. Similar techniques are already in use for automatically generating wrapper code to handle interfacing to unstable APIs, so it's definitely possible.

I realise that such a system would probably scare the hell out of RMS, but he should know well enough that any obfuscatory changes are easily undone. In some ways, it's like the war between software protections and crackers - once the crackers developed tools to analyse and automatically bypass any local serial-number type protections, they solved the problem generally and DRM was forced to go online. I'd be interested to see what RMS would try if faced with such a solution...

Re: Extracting the abstract syntax tree from GCC

#23
This is why I prefer the BSD license for everything I do. In Stallman's universe, "freedom" only exists as long as it furthers his cause. What a waste. As far as I'm concerned, if I write something and release the source, I'm more than happy with people using it for whatever they want.

Re: Extracting the abstract syntax tree from GCC

#25

Just let GCC die already. Not only is LLVM free from this issue, it's technically superior across the board. The general replacement of GCC with LLVM in most applications appears sufficiently inevitable that investing more effort into GCC is wasteful.

llvm cant build a working Linux kernel.

Re: Extracting the abstract syntax tree from GCC

#26
post #17

Earlier quoted context omitted.

And the absolute certainty that without getting buy-in from RMS, the API would be constantly changed to frustrate such a AST dumping API. Unless GCC and/or EMACS (using LLVM) gets forked. Again.

True, but it takes effort to change the API, and even if they did something obfuscatory to it automatically with every new version, it wouldn't be all that hard to write something that parses GCC's source code or compiles programs specifically designed to exercise the right paths - and grabs the right bits automatically; a meta-AST-extractor. Similar techniques are already in use for automatically generating wrapper…

Indeed, but that route requires forking GNU Emacs and earning RMS's eternal hostility, along with his fanbois and girls. Which I can attest is no fun (I worked for UniPress on the EMACS that he illicitly forked GNU Emacs from, I went from a LMI Lisp Machine ally, and later roommate when he started GNU, to a "Software Hoarder" (note UniPress shipped their Emacs with undistributeble source)). It's a very big thing to split one or more communities like that, a potentially fatal thing, and this discussion has brought out that GNU Emacs is already losing a lot of mind share in the otherwise sort of natural for it C and C++ communities.

One problem here is that RMS is not a C++ programmer (not an entirely unwise decision!), the languages he programs in, to the extent he does anymore, don't require this sort of thing, and apparently doesn't appreciate how this is a deal breaker for modern C++ programming. Or doesn't care, and how that's decreasing GCC mindshare as well.

Because of this policy with GCC, 99.999% plus of the the academic mind share is with LLVM, and the only thing keeping it from taking over is it's relative paucity of backends.

Re: Extracting the abstract syntax tree from GCC

#27

Just let GCC die already. Not only is LLVM free from this issue, it's technically superior across the board. The general replacement of GCC with LLVM in most applications appears sufficiently inevitable that investing more effort into GCC is wasteful.

llvm cant build a working Linux kernel.

I'm pretty sure no one is working hard to fix that right now because GCC does, and for many many more backends, especially solidly.

We'll really know things are at a tipping point when LLVM starts to acquire a bunch of solid back ends. I will personally count it as all over if/when Atmel AVR 8 bit is supported.

Re: Extracting the abstract syntax tree from GCC

#28

Just let GCC die already. Not only is LLVM free from this issue, it's technically superior across the board. The general replacement of GCC with LLVM in most applications appears sufficiently inevitable that investing more effort into GCC is wasteful.

llvm cant build a working Linux kernel.

It can. Patches are here: http://llvm.linuxfoundation.org/index.php/Main_Page

Re: Extracting the abstract syntax tree from GCC

#29
post #21

Earlier quoted context omitted.

The fear that someone else might be "better" than you so you're intentionally going to make it impossible for them to even compete is a really dumb argument. Imagine if this was done in sports. And that seems to have been the whole intention behind this. Make sure no non-GPL backend can be used because god forbid it's better than ours. The shame!

> The fear that someone else might be "better" than you so you're intentionally going to make it impossible for them to even compete is a really dumb argument. Imagine if this was done in sports. It is done in sports. Most sports forbid you from taking drugs that enhance your performance, or are seggregated by sex in order to account for the "natural" (?) unequal distribution of muscular mass across sexes, because we…

"if you take code, you must give back code."

That's not the intention. It's a forward mechanism, not a backwards one. If you distribute code to person/company/entity X then you must also distribute the source code, or provide a way for X to get the source code.

If you make changes but never distribute the code then you don't need to distribute your modified code to anyone. If you only provide a service then you don't need distribute the code to anyone. Even if you modify gcc, sell me a copy, and distribute the changed source code to me, that doesn't mean you or I need to give the changes back to the gcc project.

The "fear", as I understand it, is that the Linux kernel and gcc are the two biggest GPL-based projects. If gcc is diminished, then fewer people will be aware of, much less agree with or advance, the ideals of software freedom. The technical advantages of gcc are used as marketing for software freedom.

Hiding GNU projects behind commercial and proprietary solutions front-ends reduces the marketing. Hence also the issue about "GNU/Linux" as "Linux" diminishes the marketing of the GNU project.

Re: Extracting the abstract syntax tree from GCC

#30
post #12

Earlier quoted context omitted.

The issue is not that the plugin wouldn't be gpl; it would. The concern is that the AST dumped is not code, but an artifact, and thus can be used by proprietary software and make proprietary software better. I could write a program that compiles your gcc-produced AST for a new architecture, and not GPL it because the AST itself probably isn't GPL protected. That's the fear.

The fear that someone else might be "better" than you so you're intentionally going to make it impossible for them to even compete is a really dumb argument. Imagine if this was done in sports. And that seems to have been the whole intention behind this. Make sure no non-GPL backend can be used because god forbid it's better than ours. The shame!

The fear isn't that there will be competition, it is that there will be competition that sits on your back for the first 90% of the marathon and then outsprints you on the final 400m.

You are free to compete, but have run the whole marathon.

Post reply on HN