Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

New LLVM Debugger Subproject Already Faster Than GDB

timothy posted more than 4 years ago | from the pop-will-eat-itself dept.

GNU is Not Unix 174

kthreadd writes "The LLVM project is now working on a debugger called LLDB that's already faster than GDB and could be a possible alternative in the future for C, C++, and Objective-C developers. With the ongoing success of Clang and other LLVM subprojects, are the days of GNU as the mainstream free and open development toolchain passé?" LLVM stands for Low Level Virtual Machine; Wikipedia as usual has a good explanation of the parent project.

cancel ×

174 comments

Sorry! There are no comments related to the filter you selected.

New Project, not feature complete (5, Insightful)

ustolemyname (1301665) | more than 4 years ago | (#32526992)

So maybe a better way of putting it is "not yet as slow"

Re:New Project, not feature complete (1)

drdrgivemethenews (1525877) | more than 4 years ago | (#32527092)

Exactly what I was going to say. Same story, different day.

Re:New Project, not feature complete (2, Informative)

c++0xFF (1758032) | more than 4 years ago | (#32527474)

So far I've been impressed with LLVM's capability to write clean, effective code. It's not perfect, but it seems to be standing up to the effects of time.

The exception is code that bitrots as the project progresses: someone contributes a backend, but then nobody uses or updates it as time goes on. I can't fault the project, though ... the development model relies on contributions from interested individuals. If nobody is interested, the code dies off.

Overall, I'd call LLDB a welcome project, and hope that it stays just as successful far into the future.

Re:New Project, not feature complete (1)

ustolemyname (1301665) | more than 4 years ago | (#32528188)

Oh, I agree, LLVM is great. But it is silly to compare a mature, feature complete project to a new project on the basis of speed (though I think ultimately LLDB will remain faster).

Success? (1)

Bill_the_Engineer (772575) | more than 4 years ago | (#32527016)

If it wasn't for this slashvertisement, I wouldn't have heard of it.

Personally I like my toolchain to have some heritage and age, so at the moment GNU is a safe choice for me.

Re:Success? (5, Interesting)

mmkkbb (816035) | more than 4 years ago | (#32527072)

LLVM interoperates with GCC already. From the WIkipedia entry: "LLVM was originally written to be a more aggressive, higher performance system for the existing GCC stack,[3] and many of the GCC front-ends have been modified to work with it. LLVM currently supports the compilation of C, C++, Fortran, Objective-C, Ada, D, using front-ends derived from version 4.0.1 and 4.2 of the GNU Compiler Collection (GCC)."

Re:Success? (0)

Anonymous Coward | more than 4 years ago | (#32528836)

Yes, but soon it won't need to as new frontends (currently just clang, which covers C/C++/Objective-C) are developed.
Using the GCC frontends is a (relatively) temporary measure.

Re:Success? (2, Informative)

Gerald (9696) | more than 4 years ago | (#32527470)

Personally I like my toolchain to have some heritage and age, so at the moment GNU is a safe choice for me.

I need a good static analyzer [llvm.org] , which is nonexistent in the GNU toolchain.

Re:Success? (4, Informative)

mini me (132455) | more than 4 years ago | (#32528026)

Apple uses the work of the project extensively in Xcode for OS X/iOS development. You might not have heard of it, but a lot of people have used it.

Re:Success? (1)

maxume (22995) | more than 4 years ago | (#32529446)

Apple makes significant contributions to the work of the project. For instance, things like the debugger discussed in this here story.

Grammar (2, Funny)

Anonymous Coward | more than 4 years ago | (#32527030)

is the days of GNU as the mainstream free and open development toolchain passé?

Does I not understand some grammatical concept here?

Re:Grammar (1)

kthreadd (1558445) | more than 4 years ago | (#32528110)

Thanks for the heads up. I appreciate it.

I'm I the only one (0)

Anonymous Coward | more than 4 years ago | (#32527070)

that thinks the image tagged on this story looks like some horribly malformed cartoon penis?

Re:I'm I the only one (0)

Anonymous Coward | more than 4 years ago | (#32528518)

What has been seen cannot be unseen, this is like Stallman and his toe cheese [youtube.com] .

Everybody please enjoy your penisy GNU stories now.

How often does debugger speed matter? (4, Insightful)

pthisis (27352) | more than 4 years ago | (#32527076)

It's possible that LLVM-based tools may be approaching the point where they could supplant GCC, but this project doesn't seem all that important to that goal. There are definitely niches where a fast debugger matters, but that's exactly what they are--niches. A faster debugger is very, very low on the list of things that would help you compete with the GCC toolchain.

Things like supporting variadic templates, having a wider array of backends, and the like are far more important if you want to displace GCC--the backends, in particular, make clang a total non-starter for many embedded developers.

That's not to say the fast debugger isn't a good development--for things that need it, it's very valuable indeed. But the attempted spin of the blurb seems to miss the point.

Re:How often does debugger speed matter? (2, Insightful)

Incster (1002638) | more than 4 years ago | (#32527246)

Debugger speed only matters whey you are debugging. Anything that significantly speeds up the edit/compile/debug cycle is very welcome.

Re:How often does debugger speed matter? (4, Insightful)

pthisis (27352) | more than 4 years ago | (#32527746)

Debugger speed only matters whey you are debugging. Anything that significantly speeds up the edit/compile/debug cycle is very welcome.

Debugger speed barely matters for a lot of debugging, though. 85% of the time I run a debugger, gdb takes 1 second to start up and spends most of its time sitting waiting for input from me.

There are niches where a faster debugger matters, and if you're in one of those then it's very, very valuable, but it's hardly the sort of killer feature that's going to put LLVM over the top wrt GCC. There are a _ton_ of other LLVM features that are more important in that battle.

Re:How often does debugger speed matter? (4, Insightful)

c++0xFF (1758032) | more than 4 years ago | (#32527302)

How often does debugging speed matter? That's like asking someone "How often does compiler speed matter?"

The answer is ... depends on who you are. Many/most people simply don't care. To others, it's a key feature.

I hate how slow GDB can be sometimes. Improving that speed will only make my programming experience better and my life easier.

Will I chose LLVM over GCC simply because of LLDB? Of course not! But for those times that LLVM is a good choice (and yes, I've used it before because it can be a better compiler suite), I'll be glad someone said "GDB is too slow. We can do better!"

P.S. Clang is a front-end to LLVM, not a back-end. The LLVM embedded back-ends are still young, admittedly, but it's relatively easy to create new ones for the one-off embedded environments. And that can make it an ideal project for some developers.

Re:How often does debugger speed matter? (5, Insightful)

pthisis (27352) | more than 4 years ago | (#32527830)

How often does debugging speed matter? That's like asking someone "How often does compiler speed matter?"

The answer is ... depends on who you are. Many/most people simply don't care. To others, it's a key feature...
Will I chose LLVM over GCC simply because of LLDB? Of course not! But for those times that LLVM is a good choice (and yes, I've used it before because it can be a better compiler suite), I'll be glad someone said "GDB is too slow. We can do better!"

I think we're in violent agreement there; my only objection was to positing LLDB as a possible killer feature that prompts mass switching away from GCC.

Clang is a front-end to LLVM, not a back-end. The LLVM embedded back-ends are still young, admittedly, but it's relatively easy to create new ones for the one-off embedded environments. And that can make it an ideal project for some developers.

Sure, but this is where GCC has a huge leg up--as the grey-bearded old project, it already has a ton of back-ends. If I'm working on a new embedded project and I have the choice of using GCC (where writing a back-end is painful, but it's already written) or LLVM (where it's comparatively easy, but needs to be done) I'm going to lean strongly toward GCC.

Now, LLVM's flexibility here means that hopefully it will catch up quickly, and with new platforms could easily garner support faster than GCC. Ultimately, barring a major GCC rearchitecture, ease of back-end development will be a big feather in LLVM's cap. But in the mid-term, the plethora of platforms GCC supports is still a check in its favor.

Re:How often does debugger speed matter? (1)

bonch (38532) | more than 4 years ago | (#32528806)

I think we're in violent agreement there; my only objection was to positing LLDB as a possible killer feature that prompts mass switching away from GCC.

Clang is already that killer feature.

Re:How often does debugger speed matter? (1)

Shinobi (19308) | more than 4 years ago | (#32528866)

"Sure, but this is where GCC has a huge leg up--as the grey-bearded old project, it already has a ton of back-ends. If I'm working on a new embedded project and I have the choice of using GCC (where writing a back-end is painful, but it's already written) or LLVM (where it's comparatively easy, but needs to be done) I'm going to lean strongly toward GCC."

For me, that's what makes LLVM so much better, since it's a market opportunity for me. I can offer to develop back-ends for my customers, with full support from me in the contract, without having all the HORRIBLE HORRIBLE OH MY GOD MY EYES THE GOGGLES THEY DO NOTHING pain of working with the GCC internals. That also includes easier to design a solution that uses an architecture more suited to the particular task that would otherwise not be considered, due to lack of a decent back-end for GCC for example.

Re:How often does debugger speed matter? (3, Informative)

TheRaven64 (641858) | more than 4 years ago | (#32529160)

It's also worth noting that a number of the GCC back ends are not really working. This is a huge problem for OpenBSD and NetBSD, which support architectures that have painfully bit-rotted support in GCC and so have had to stay with ancient versions which can't compile a lot of newer code (e.g. no C99 support). The further that you get from x86, the less likely GCC is to actually work.

The same is true of LLVM, for example SPARC64 support is unfinished and IA64 is now officially unsupported (which greatly upset both Itanium users), but at least the code is relatively easy to jump in and play with.

As for the 'HORRIBLE HORRIBLE OH MY GOD MY EYES THE GOGGLES THEY DO NOTHING pain' of working with GCC internals, that's not limited to the back end. I wanted to add Objective-C 2 support to FSF GCC. It turned out to be less effort to completely implement Objective-C code generation support in clang than extend the mostly working code in GCC. And this is in spite of the fact that I passionately detest C++, yet clang is written in C++ and GCC in C.

Re:How often does debugger speed matter? (1)

c++0xFF (1758032) | more than 4 years ago | (#32529554)

And this is in spite of the fact that I passionately detest C++, yet clang is written in C++ and GCC in C.

I've found Clang and LLVM to be marvelous examples of how to write C++ code. Not perfect examples, mind you, but the code is very well written overall.

C++ exaggerates the lack of skills that many programmers have. Take that as a sign of the type of programmers working on LLVM.

I don't want to make it sound like only bad programmers wrote GCC, as there are other factors to consider (bit rot, passage of time, code complexity, and lack of foresight).

Re:How often does debugger speed matter? (0)

Anonymous Coward | more than 4 years ago | (#32529954)

IA64 is now officially unsupported (which greatly upset both Itanium users)

Here's my nomination for thread winner...

Re:How often does debugger speed matter? (0)

Anonymous Coward | more than 4 years ago | (#32529870)

It could be argued that LLVM is pushing gcc to improve. GCC originally was written with *deliberately* undocumented internals and made hard to extend in a modular fashion because RMS feared that would give rise to proprietary backends. This sort of handwringing held up things like the plugins branch for years -- not over technical merits, but license enforcement. Well they've now seen the light and have merged the plugins branch into 4.5. GCC's internals are still lovecraftian, but at least we're seeing high-level APIs that let you avoid it. I suspect these improvements were very much driven by the standards being set by LLVM.

Re:How often does debugger speed matter? (4, Insightful)

samkass (174571) | more than 4 years ago | (#32527346)

Indeed, I think that LLVM's ability to create more symbolic representations of code that are easier to instrument and refactor during debugging are far more valuable than the pure speed. While LLVM is proving to be faster than the gcc/gdb toolchain in every metric from compile to runtime speed, that's not even its best selling point.

Re:How often does debugger speed matter? (1)

menkhaura (103150) | more than 4 years ago | (#32528694)

I would LOVE to see some comparison/benchmark that shows LLVM generated binaries being faster than GCC generated. CLang cries high and low about compiling faster than GCC, but they don't say anything about resulting executable speeds.

Re:How often does debugger speed matter? (1)

Halo1 (136547) | more than 4 years ago | (#32528886)

I would LOVE to see some comparison/benchmark that shows LLVM generated binaries being faster than GCC generated. CLang cries high and low about compiling faster than GCC, but they don't say anything about resulting executable speeds.

GCC still generates faster code overall as far as the SPEC benchmarks are concerned, but LLVM isn't too shabby (and in some cases beats GCC). See http://vmakarov.fedorapeople.org/spec/ [fedorapeople.org] (bottom two sub-entries in the left frame, check the SPECINT/SPECFP2000 score graphs)

Re:How often does debugger speed matter? (1)

TheRaven64 (641858) | more than 4 years ago | (#32529270)

The biggest limitation with LLVM right now is that no one has yet written any autovectorisation passes for it. This means that any code that gets a speedup from autovectorization in GCC will likely be faster than when compiled with LLVM. You can find a lot of benchmarks if you use a search engine, but few of them show more than a 5-10% speed difference in either direction.

As the grandparent said, the real benefit of LLVM is that it's really easy to add custom passes. For example, I've written a handful of language-specific ones for the GNUstep Objective-C 2 runtime. I have a few microbenchmarks that run in around 20% of the time (one that runs in 5% of the time) when compiled with LLVM + my opts than when compiled with GCC. Obviously, these are microbenchmarks and so don't reflect the real speed improvement that you'll get (real code does a lot of things other than the things that are tested), but they make Objective-C code run within a few percent of the speed of C code, and Smalltalk within about 20% (unless you use floating point - my Smalltalk floating point code is still really terrible), which is fast enough for me.

It limits what your debugger can do (1)

DLPierson (8772) | more than 4 years ago | (#32527588)

For simple manual stepping, etc. debugger speed is probably not that important. Have you ever tried to really use watchpoints? Given up after your program slowed to a crawl?

We had a debugger that could run many watchpoints at almost full program speed some time ago, see http://www.netilium.org/~mad/dtj/DTJ/DTJK07/ [netilium.org] for details. The key point is that Parasight was fast enough to make tools like this useable.

Re:How often does debugger speed matter? (1)

David Gerard (12369) | more than 4 years ago | (#32528220)

A second good free compiler will be of tremendous use to the world. gcc is fine, but competition will make both better. It'll also make open source code better, as gccisms get cleaned out of code.

Re:How often does debugger speed matter? (1)

pthisis (27352) | more than 4 years ago | (#32529262)

A second good free compiler will be of tremendous use to the world. gcc is fine, but competition will make both better.

Definitely. The more options, the better.

It'll also make open source code better, as gccisms get cleaned out of code.

This I'm less sure on; clang goes out of its way to support a lot of gccisms (as do other compilers--e.g. the closed-source Intel compiler). It'll help some around the edges, for sure, but a lot of the most common gcc extensions are with us for the foreseeable future even with viable alternative compilers.

Re:How often does debugger speed matter? (1)

David Gerard (12369) | more than 4 years ago | (#32529424)

So they'll become part of the next standard ;-)

Re:How often does debugger speed matter? (2, Insightful)

TheRaven64 (641858) | more than 4 years ago | (#32529096)

When I'm debugging LLVM itself, it takes gdb several minutes in my machine to load the debugging symbols. A recompile means that it has to go through this process again. Loading the symbols actually takes longer than the test-edit-recompile cycle in many cases. It's so slow that most of the time I just do a release build and add printf statements, rather than using an interactive debugger. If LLDB is significantly faster, this might change, although currently it's Darwin-only (which was somehow omitted from the summary).

Nice (2, Interesting)

Jorl17 (1716772) | more than 4 years ago | (#32527098)

I like LLVM, but I love TenDRA [wikipedia.org] .

Re:Nice (1)

kescom (45565) | more than 4 years ago | (#32527284)

Why TenDRA?

Re:Nice (1)

Jorl17 (1716772) | more than 4 years ago | (#32528406)

I don't quite know. I wrote (or started writing) my libc implementation and had TenDRA around. Thus, I decided to write my libc and C++ implementation working both in TenDRA and GCC. I never really finished it, but I did get most of libc done (i/O and all), and I managed to implement a simple iostream standard-compliant c++ implementation within TenDRA.

Depends... (4, Insightful)

fuzzyfuzzyfungus (1223518) | more than 4 years ago | (#32527146)

"s the days of GNU as the mainstream free and open development toolchain passé?"

I suspect that that will depend, in part, on how LLVM ends up being used. Since it is under a BSD-esque license, LLVM itself is definitely a candidate for being the "mainstream free and open development toolchain"; but only if the majority of real-world support scenarios don't involve proprietary actors taking advantage of that fact. In that case, it'll pretty much just end up being the core of a large number of binary, proprietary, BSPs and toolchains.

Given the good things that are said about its technical characteristics, I would hope that that doesn't happen; but the potential exists.

Re:Depends... (3, Insightful)

should_be_linear (779431) | more than 4 years ago | (#32527254)

if they achieve +10% of avg. performance against gcc (not gdb!) on AMD64 and/or ARM platform, everyone will start using it pretty soon. Until then it cannot replace gcc. Unless compiler is in some way seriously broken, its only important characteristic is performance of generated code.

Re:Depends... (1)

mmkkbb (816035) | more than 4 years ago | (#32527298)

Even if the performance boost of generated code is not that high, a performance boost on generatING code would be a wonderful and welcome bonus

Re:Depends... (1)

c++0xFF (1758032) | more than 4 years ago | (#32527690)

The real benefit to LLVM/Clang is the internal representation.

It's true that, for the majority of users, the only thing that matters is that C/C++ goes in and x86 machine code comes out.

But a good IR allows for interesting tools that step beyond the traditional development cycle. How about an IDE that has intimate knowledge of the code? How about a JIT with dynamic optimizations? How about static analysis to find bugs faster and easier?

The developer doesn't really care about the IR ... but the result is a great variety of tools to make life better. That's why I call a "wonderful and welcome bonus."

Re:Depends... (5, Interesting)

joe_bruin (266648) | more than 4 years ago | (#32528044)

if they achieve +10% of avg. performance against gcc (not gdb!) on AMD64 and/or ARM platform, everyone will start using it pretty soon. Until then it cannot replace gcc. Unless compiler is in some way seriously broken, its only important characteristic is performance of generated code.

Intel's ICC compiler produces code that is more than 10% faster for x86/x86_64 than GCC (last I checked). ARM's RVCT compiler produces code that is 30% faster than GCC (today)! Why is anyone still using GCC then? Money, MY FREEDOM, and compatibility with gcc-only code are the leading candidates. Interestingly, LLVM solves all three of those issues for most people, plus it has the performance advantage.

Re:Depends... (3, Interesting)

Halo1 (136547) | more than 4 years ago | (#32528934)

ARM's RVCT compiler produces code that is 30% faster than GCC (today)!

Since ARM forbids publishing any kind of performance or code size comparisons between RVCT and other compilers, I'm wondering where you got that number.

Re:Depends... (1)

smcdow (114828) | more than 4 years ago | (#32529442)

Why is anyone still using GCC then?

In a nutshell, portability.

Well written gcc/g++ code will compile using gcc/g++ on many, many platforms and operating systems with no changes to the source. The other compilers mentioned, besides being non-free in various ways, won't do that. For me, the portability angle is a whole lot more important than the freedom angle.

Re:Depends... (2, Insightful)

coredog64 (1001648) | more than 4 years ago | (#32530026)

Having struggled mightily to compile allegedly portable code using GCC on both Solaris/SPARC and IRIX, I guess that would
mean there's a dearth of well written code.

Re:Depends... (0)

Anonymous Coward | more than 4 years ago | (#32528256)

To a large degree, that's correct. But one of clang's (C compiler written specifically for LLVM) reasons for existence is better diagnostics and ability to hook into IDEs. I like clang's diagnostics compared to gcc's (they help pinpoint problems somewhat better), so even if clang is roughly equal to gcc in code generation (which it has been in my tests), I might prefer clang over gcc.

Currently I use both and I really don't have a problem with either.

Re:Depends... (0)

Anonymous Coward | more than 4 years ago | (#32528744)

How about the platform that matters, x86?

Re:Depends... (0)

Anonymous Coward | more than 4 years ago | (#32529420)

He said AMD64, and that refers to the only variety of x86 that really matters these days. Sure, there's a lot of 32-bit hardware around still, but it's in decline and most of it is not being used to run new software any more.

gcc is seriously broken (2, Insightful)

Gary W. Longsine (124661) | more than 4 years ago | (#32529750)

Well, the gcc is seriously broken in at least two interesting ways, both of which are fixed by The LLVM Project:
  1. the GPL, which provides counter-incentive to major contributions from corporate funded development;
    the LLVM fix: a BSD style, fully free, as in "free" (not as in "beer" or any other not-quite-free internet-libertarian-testament-to-education-failure construct) not encumbered in any way license, the success of which is evidenced by substantial corporate contribution to the LLVM project from several different companies, and
  2. the ancient monolithic architecture, which provides a very high barrier to entry for even highly motivated potential contributors, and which stifles compiler innovation.
    the LLVM fix: a modular architecture, with a well defined Intermediate Representation which can be used between arbitrary compiler stages, and a project principle that each modular component should be implemented a library which an be linked into arbitrary higher level programs, so that compiler components can be shared with the debugger and the IDE, or example, the success of which is evidenced by XCode 4, and the reuse of LLVM components in the LLDB Debugger Project, and in other ways.

Making a faster compiler which emits code with superior optimization (e.g. runs faster on given target hardware) than gcc just gives The LLVM Project bragging rights, which is a "nice to have" but probably not really an essential technical feature (it may be an essential marketing feature for the project, though).

Re:Depends... (3, Insightful)

Anonymous Coward | more than 4 years ago | (#32527286)

So what? If that core stays powerful and maintained actively by a community, the fact that closed-source derivations exist does not matter. Open source projects will stick to the open version. Is X.Org any dangerous for being BSD-like licensed?

Re:Depends... (2, Informative)

Renegade88 (874837) | more than 4 years ago | (#32527292)

Ah, a staple argument from GPL fanatics. No, your scenario is not realistic. Even if somebody makes a proprietary branch, that doesn't deprive anybody of the mainstream branch. Only GPL freaks are concerned about this. The rest of us realize that maintaining a private fork of a large project like this an enormous pain in the rear and it's much more convenient for the improving entity just to give the fix back and let project absorb it.

Unlike GCC, outsiders can successfully provide patches and bug reports to LLVM. The process isn't so incredibly oppressive that people just don't bother.

Anyway, other major BSD-like projects don't suffer from private forks, and there's no reason to think LLVM will either.

Re:Depends... (1)

cheesybagel (670288) | more than 4 years ago | (#32527490)

Like BSD itself? It was forked how many times?

Anyway the problem with BSD is not forking. It is closed proprietary forking like what Transgaming does.

Re:Depends... (0, Troll)

ToasterMonkey (467067) | more than 4 years ago | (#32528868)

Like BSD itself? It was forked how many times?
Anyway the problem with BSD is not forking. It is closed proprietary forking like what Transgaming does.

I don't think he said a BSD license PREVENTS forking. Nor does the GPL prevent forking into other GPL projects.
Is there a staggering amount of non-free BSD improvements locked up somewhere? .. also, what's wrong with what Transgaming does? They contributed back to WINE, and in bigger ways then they would if it were a GPL project from the beginning. They would not be where they are today if they didn't have some protection of their investment. I wonder how symbiotic their relationship with WINE is now?

What exactly does the GPL protect free software against? Jealousy? Irrational fear of forks? You see the same crap when someone decides to sell another's open source project and offer paid support for it. Bunch of jealousy.

The only real pragmatic benefit I see is using it to protect your own investment in an open project from other commercial interests until the time comes that you fork it yourself to commercialize it. Not exactly ideologically pure mind you.. and the fear of losing something that doesn't go anywhere prevails. I think freet*rds are completely aware that their work (for the ones that don't entirely consume free shit) and ideas are worth money, but they are afraid of success?

Re:Depends... (0)

Anonymous Coward | more than 4 years ago | (#32527524)

Thank the Gods the KDE devs went with GPL and not BSD for KHTML, aka WebKit now...

Re:Depends... (1)

Haeleth (414428) | more than 4 years ago | (#32529458)

Why? Apple have maintained Darwin as an open-source project even though the BSD license meant they didn't have to. And they are contributing very heavily to the open-source releases of LLVM, even though the BSD license means they don't have to. They have enough positive incentives to do it that coercion is unnecessary.

Re:Depends... (1)

Jah-Wren Ryel (80510) | more than 4 years ago | (#32527570)

Ah, a staple argument from GPL fanatics. No, your scenario is not realistic. Even if somebody makes a proprietary branch, that doesn't deprive anybody of the mainstream branch.

Nope, but if those proprietary forks compete against anyone doing work on the main branch those people now have a strong incentive to stop contributing because their own work would be used against their own financial interest. At which point the entire project starts to stagnate.

Unlike GCC, outsiders can successfully provide patches and bug reports to LLVM. The process isn't so incredibly oppressive that people just don't bother.

Which has nothing to do with the GPL. LLVM could just as easily become insular and slowed by inertia - look at XFree86 with their licensing being practically the same as BSD and how that all worked out.

Anyway, other major BSD-like projects don't suffer from private forks, and there's no reason to think LLVM will either.

WINE did, proprietary forks are precisely why they went to the LGPL.

Re:Depends... (2, Insightful)

Renegade88 (874837) | more than 4 years ago | (#32528146)

I didn't quite understand that. Who stops contributing? The creators of the private fork or some third party that's duplicating the functionality on the main branch?

One of the big misconceptions by GPL people is they think that if the license is GPL, the potential contributor will be "forced" to contribute back. No, he won't. Anyone that does not wish to contribute will not, regardless of license. He'll either use GPL code, but not distribute, use another project, or roll his own. The GPL did not force anyone to contribute in those cases.

Reading GCC mail-lists are quite entertaining -- they spend a lot of time discussion legal action, potential lawsuits (defensive and offensive), etc. This kind of frequent litigious discussion just doesn't seem to occur on BSD project sites. By the way, GPL folks, stop being offended for BSD projects when some commercial entity uses their code. It's allowed in the license and the BSD people aren't stupid. They are okay with the use of the code so you should be too. Stop using the Microsoft TCP/IP example. Nobody cared. They were probably happy that TCP/IP was reinforced as the defacto standard.

Re:Depends... (2, Informative)

Jah-Wren Ryel (80510) | more than 4 years ago | (#32528440)

I didn't quite understand that. Who stops contributing? The creators of the private fork or some third party that's duplicating the functionality on the main branch?

Neither. The people who had previously been contributing to the main branch and then realized that a private fork was standing on their shoulders and being used to compete against them. See how CodeWeavers wasn't happy about Transgaming making a proprietary fork of Wine and then competing with them by selling what was in some ways a CodeWeavers++ product. By moving to LGPL, Transgaming could not take any more of CodeWeavers work and use it to undercut CodeWeavers in the market.

Re:Depends... (1)

Renegade88 (874837) | more than 4 years ago | (#32528828)

Fair enough, but a contributor knows the terms of the license going in. If they have a moral issue with this possibility, then they shouldn't contribute in the first place.

I'm only vaguely familiar with the Transgaming thing, but I do support the LGPL. I think that's a pretty good license. Too bad the FSF wish it didn't exist.

Re:Depends... (1)

losinggeneration (797436) | more than 4 years ago | (#32528606)

One of the big misconceptions by GPL people is they think that if the license is GPL, the potential contributor will be "forced" to contribute back. No, he won't. Anyone that does not wish to contribute will not, regardless of license. He'll either use GPL code, but not distribute, use another project, or roll his own. The GPL did not force anyone to contribute in those cases.

That's just how things go. The not distributing and rolling their own can be hard in situations such as compilers or development tools. Using a different project is always an option, but the same is true in the commercial world. It's the same as choosing a library to use based on the license price, features, whatever. You're going to choose what works best for the project. If not contributing back and keeping the source closed is a deal breaker for the project, GPL isn't going to be an option if you have to release/distribute the program. So you're right, yet, there are still plenty of companies that try to use GPL code without releasing the source till legal action is finally threatened.

By the way, GPL folks, stop being offended for BSD projects when some commercial entity uses their code. It's allowed in the license and the BSD people aren't stupid. They are okay with the use of the code so you should be too. Stop using the Microsoft TCP/IP example. Nobody cared

It's typically not used as an example of them doing anything legally wrong, just more ethically (in their eyes.) GPL advocates at least want the option of being able to incorporate the changes back into the main line, or being able to make further changes to the code that was forked. Someone in another thread said it quite well: BSD gives more freedom to the developers, and GPL gives more freedom to the users. And you're right, the BSD devs didn't/don't care if their code is used commercially without releasing their changes. It's a non-issue to them because they're developers and care more about making developers' lives easier.

Re:Depends... (1)

Renegade88 (874837) | more than 4 years ago | (#32528946)

A very nice response, thank you. I disagree a bit with the last paragraph. The LGPL would be sufficient to protect getting the changes back into the project that they started. The GPL exists to get another projects to change their license. Yes, you are right that the GPL wants to improve the users lives, but they are doing that by trying to convert projects that they really had nothing to do with to the GPL. The stated goal is all proprietary software is evil and all software should be GPL by whatever means necessary. This latest trend of GPL projects relicensing BSD code so the BSD project can't use the improvements makes me seethe those. The GPL adocates say proprietary software is evil because it keeps code from the author, but then the GPL does the same thing to truly free licensed projects.

Re:Depends... (0)

Anonymous Coward | more than 4 years ago | (#32529992)

GPL advocates see this as collateral damage, unfortunate but necessary for fighting the good fight. No point to argue, it's as potent as religion to them. You can't prove a self-convinced freedom fighter wrong.

Re:Depends... (0)

Anonymous Coward | more than 4 years ago | (#32529948)

Someone in another thread said it quite well: BSD gives more freedom to the developers, and GPL gives more freedom to the users. And you're right, the BSD devs didn't/don't care if their code is used commercially without releasing their changes. It's a non-issue to them because they're developers and care more about making developers' lives easier.

You have it all wrong. BSD programmers usually think they have no say in the matter, because they write code. The politics of digital "freedom" is something that they have no particular insight in. User's rights aren't a battle many consider themselves empowered nor often educated in to make a change.

The fact that the overwhelming majority of code coming out of research departments is licensed BSD/MIT should be spell-breaking to the GPL crowd. But, this somehow reinforces belief, similar to telling a theist that his Bible is made-up fiction.

Re:Depends... (1)

bonch (38532) | more than 4 years ago | (#32528898)

Nope, but if those proprietary forks compete against anyone doing work on the main branch those people now have a strong incentive to stop contributing because their own work would be used against their own financial interest. At which point the entire project starts to stagnate.

Another hypothetical. I especially like how you bring up an imaginary "financial interest" from people doing volunteer work on a free project.

Re:Depends... (5, Insightful)

fuzzyfuzzyfungus (1223518) | more than 4 years ago | (#32527594)

The issue, in this case, is not so much proprietary forks of LLVM itself, which(as you note) are largely not worth the effort; but situations where a given architecture, say, is supported only in the form of a proprietary distribution of the LLVM core + a proprietary code generator for the given platform. You then end with a situation where the platoform vendor saved some money; but the platform is basically closed.

It's roughly analogous to being concerned about GPL compliance in companies that make routers and other little consumer electronics widgets: Such companies generally make no modifications of broad interest to the linux kernel, so their noncompliance imperils the development of the kernel not at all; but the modifications that they do make are generally vital to being able to build your own kernel for that particular device.

You aren't concerned because the WRT-54G firmware contained novel kernel innovations that will be of use to the linux kernel generally(indeed, the stock firmware was pretty unimpressive), you are concerned because you want to know what you need to know in order to build your own kernel for that device.

Re:Depends... (1)

rahvin112 (446269) | more than 4 years ago | (#32527666)

And how many patches has Microsoft submitted to BSD? None you say? So MS took all the BSD code, modified it and tied it to Windows and never gave back any of the code? I thought you said they will give it back because it's so painful to maintain it separately? You would be right if they were taking the whole BSD system, but when someone takes a piece of the system and integrates it into another system they don't give back changes and have no motivation to do so. Regardless this has never been about community, it's the difference between BSD being free for developers and GPL being free for users that's the difference.

Re:Depends... (1)

abigor (540274) | more than 4 years ago | (#32527814)

And how many patches has Microsoft submitted to BSD? None you say? So MS took all the BSD code, modified it and tied it to Windows and never gave back any of the code?

Huh?

Re:Depends... (1)

Jah-Wren Ryel (80510) | more than 4 years ago | (#32528082)

MS hasn't used any significant BSD code for at least a decade probably much longer.
They still might have some in their telnet and ftp clients but that's about it.

Re:Depends... (1)

bonch (38532) | more than 4 years ago | (#32528952)

What are you talking about?

I can only guess you're thinking of the TCP/IP stack, which is a myth that was long ago been disproved [kuro5hin.org] .

The "GPL being free for users" statements makes you look like an ideological kook. Users don't give a shit about the license of the source code for the apps they use.

Re:Depends... (2, Informative)

c++0xFF (1758032) | more than 4 years ago | (#32527812)

It's worth noting that Apple is a big contributor (both financially and technically, I believe) to LLVM.

There's many people on Slashdot who might predict Apple would be the first to branch and "steal" LLVM code. So far, the opposite is true -- they realize the benefit of contributing back.

Re:Depends... (1)

Halo1 (136547) | more than 4 years ago | (#32529100)

It's worth noting that Apple is a big contributor (both financially and technically, I believe) to LLVM.

There's many people on Slashdot who might predict Apple would be the first to branch and "steal" LLVM code. So far, the opposite is true -- they realize the benefit of contributing back.

Those things aren't mutually exclusive (although I wouldn't call it stealing, not even between quotes, unlike the straw men you appear to be referring to). They're both open sourcing large parts of their work based on LLVM and keeping other parts closed (such as their LLVM-based OpenGL stack, and probably other things we don't even know about).

And to be clear, I'm not saying that's wrong, morally or otherwise. I'm just trying to illustrate that the world is not as black and white as you paint it and that the license allows such things (which would not be possible with something like the GPL -- and again, I'm not saying anything about whether this is good, bad or neither).

Re:Depends... (0)

Anonymous Coward | more than 4 years ago | (#32528964)

For all intents and purposes, OS X is a "private fork" of FreeBSD.

Re:Depends... (4, Informative)

samkass (174571) | more than 4 years ago | (#32527308)

Since it is under a BSD-esque license, LLVM itself is definitely a candidate for being the "mainstream free and open development toolchain"; but only if the majority of real-world support scenarios don't involve proprietary actors taking advantage of that fact.

Perhaps ironically, though, it is exactly that aspect of LLVM that has led to LLVM's accelerated development. Apple has been contributing vast resources to it, and it is quickly replacing the gcc toolchain in MacOS and iOS development. I'm quite sure that the BSD license played a large role in Apple's decision to go the LLVM route. Apple has been using it internally for years as a way to create CPU vs GPU agnostic graphics code that can run on the best available hardware, and probably wouldn't want to have had to release that aspect of their work under GPL rules.

Re:Depends... (2, Interesting)

cheesybagel (670288) | more than 4 years ago | (#32527556)

Actually I suspect the major factor in the slower GCC development was RMS's reluctance in allowing C++ code in the tree. As for Apple, they may use LLVM, but guess which compiler they use in Xcode...

Re:Depends... (2, Informative)

kthreadd (1558445) | more than 4 years ago | (#32528282)

As of Xcode 3.2 they give you the choice of four compilers. GCC 4.0, GCC 4.2, LLVM GCC 4.2 and LLVM Clang 1.0.2. The default compiler is GCC 4.2 due to compatibility reasons but it will likely change to Clang in future versions.

Re:Depends... (2, Informative)

SteeldrivingJon (842919) | more than 4 years ago | (#32528286)

Xcode offers the alternatives of GCC 4.2, GCC front end with an LLVM back end, or Clang/LLVM.

Since Clang's C++ support is still under development, it's understandable that they don't default to the clang front end.

I would be surprised if they aren't defaulting to clang/llvm by this time next year.

They're shifting gradually, but they're definitely shifting. It's my understanding that a number of the apps in Snow Leopard were built using clang/llvm.

Re:Depends... (1)

AresTheImpaler (570208) | more than 4 years ago | (#32528364)

They're shifting gradually, but they're definitely shifting. It's my understanding that a number of the apps in Snow Leopard were built using clang/llvm.

On top of that, I'll add, that if you are targeting OS X 10.6 and not using c++, Apple recommend using Clang/LLVM. At least that's what I've heard.

Re:Depends... (1)

bonch (38532) | more than 4 years ago | (#32528966)

Xcode 4 is LLVM by default.

Re:Depends... (2, Interesting)

Anonymous Coward | more than 4 years ago | (#32527642)

Apple has basically refused to touch anything licensed as GPLv3. For instance, the newest version of GCC they ship is 4.2.1, which was the last version released as GPLv2. They did start investing in LLVM before the GPLv3 was published (not sure if they started before the first draft was released), but the license change pretty much forced the switch.

Re:Depends... (1)

Jah-Wren Ryel (80510) | more than 4 years ago | (#32527934)

In that sense its a proprietary apple project for which they've opened up the parts that they think won't give anyone else a competitive advantage against them. Kind of like the way they handled the OSX kernel.

Passe (0, Troll)

ultrabot (200914) | more than 4 years ago | (#32527242)

With the ongoing success of Clang and other LLVM subprojects is the days of GNU as the mainstream free and open development toolchain passé?

No.

Re:Passe (1)

bonch (38532) | more than 4 years ago | (#32528984)

Yes, actually. Even FreeBSD wants to rid themselves of GCC.

Re:Passe (0)

Anonymous Coward | more than 4 years ago | (#32529848)

Note that FreeBSD has just imported [freebsd.org] clang to FreeBSD head.

Re:Passe (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32529858)

And all 14 FreeBSD users are rejoicing!

Fast? Why do I care if the debugger is fast? (3, Insightful)

Technomancer (51963) | more than 4 years ago | (#32527276)

Does it have to refresh constantly and run at 60fps?
The way I use debugger, most of the time it waits for input from me. My biggest gripe with gdb is how awkward to use it is and how crappy all visual overlays for gdb are, bot how fast it is.

Re:Fast? Why do I care if the debugger is fast? (3, Insightful)

mmkkbb (816035) | more than 4 years ago | (#32527336)

If you're running a debugger on a program that runs against a huge data set, and you have conditional breakpoints. That takes for. E. Ver.

Re:Fast? Why do I care if the debugger is fast? (3, Informative)

c++0xFF (1758032) | more than 4 years ago | (#32527972)

I have that exact problem and a "solution." Insert a call to raise(3) based on the condition. GDB will catch the signal and break for you.

Yeah, you have to recompile the code ... but for datasets that I deal with, that's a much quicker solution than waiting for GDB. It also works for dynamic libraries, where setting a breakpoint is about as pleasant as eating someone else's snot.

Re:Fast? Why do I care if the debugger is fast? (0)

Anonymous Coward | more than 4 years ago | (#32529588)

OMG an under exploited porn fetish! A gold mine waiting to happen!

Re:Fast? Why do I care if the debugger is fast? (0)

Anonymous Coward | more than 4 years ago | (#32527418)

I see you have never done remote debugging over a 19200 baud line.

Step wait 3 seconds. Step wait 3 seconds...

Now on a computer if I can step and it goes 'fast' yeah I do not care that it is 50% faster. If it steps pretty much as fast as I can hit next line it already is fast enough. Does it debug the way I need it to...

Re:Fast? Why do I care if the debugger is fast? (1)

losinggeneration (797436) | more than 4 years ago | (#32528212)

Big programs like Blender, Firefox, some of the more demanding open source games, and others the startup time is quite a bit longer while running through GDB. It's not the biggest issue in the world, but it would at least help. May not be high on your priority list, but waiting 30 seconds for the program to load instead of 10 or even 20 is still a big improvement.

what about the code speed? (0)

Anonymous Coward | more than 4 years ago | (#32527294)

We discussed phoronix findings already, LLVM can be useful in some situations, GCC in many others. http://www.phoronix.com/scan.php?page=article&item=gcc_llvm_clang&num=1
The debugger speed is nice to have but definitely a secondary factor when choosing compilers. Mod summary -1 flamebait.

Possible? (1)

SuperKendall (25149) | more than 4 years ago | (#32527496)

Using it already thanks.

Performance (0)

Anonymous Coward | more than 4 years ago | (#32527774)

Fast? Huh? In the absence of downright atrocious performance, the most important thing in a debugger really is how well you can inspect, analyze, and debug code with it.

You want fast problem resolution, not fast runtime.

Re:Performance (2, Informative)

SteeldrivingJon (842919) | more than 4 years ago | (#32528366)

"the most important thing in a debugger really is how well you can inspect, analyze, and debug code with it."

I'd expect that since the llvm project is already working on richer intermediate representations of code, and more informative compiler error messages, that lldb will likewise be able to provide more and better information about a program than gdb can, at least when working with executables built using clang/llvm.

For all the people asking why... (0)

Anonymous Coward | more than 4 years ago | (#32528036)

There are 2 main reasons (at least from the way LLDB appears to be faster than gdb):

Resource constrained systems like phones & other embedded devices where debugging on device is made more difficult (then you have to deal with gdbserver & the awkward mess that can be).
Extremely large projects where you have lots of symbols.

I doubt conditional breakpoints are helped here unless LLDB does this in a different manner somehow.

(plcUs one Informative) (-1, Redundant)

Anonymous Coward | more than 4 years ago | (#32528084)

to get some eye I burnt out. I were taken over AAl major surveys 200 ruuning NT 40,000 workstations these challenges personal rivalries Don't be a sling

So what? (2, Insightful)

rawler (1005089) | more than 4 years ago | (#32528646)

Seriously? The mere existence of a debugger project for LLVM, reportedly faster (whatever does that mean for a debugger?) than gdb, leads to the question of GCC as a project has it's days numbered?

1. LLDB is AFAIU only for MacOSx yet, and x86-(64). Then what about all other combinations of platforms that make up ~99% of install base (yes, counting embedded) where GCC reigns supreme?
2. It's a friggin toddler! Doesn't mean it won't grow up into something fantastic, doesn't mean it will!
3. PERFORMANCE is the key sales-point? What about the multi-thread-debugging everyone else seems to care about?

Don't get me wrong. Noone would like to see competition in the open-source-sphere than I do, especially for such entrenched segments as GCC. But LLDB as of yet doesn't really affect things at all IMO.

Re:So what? (1)

bonch (38532) | more than 4 years ago | (#32529012)

I guess you haven't been following the Clang/LLVM project and how it's superior to GCC on both a technical basis and a political one. GCC's days really are numbered, and this is one of the last pieces of the puzzle.

Who needs debuggers... (0)

Anonymous Coward | more than 4 years ago | (#32529324)

...when there's printf?

Trying to be clever in the summary, and failing (1, Informative)

Anonymous Coward | more than 4 years ago | (#32529600)

[quote]With the ongoing success of Clang and other LLVM subprojects is the days of GNU as the mainstream free and open development toolchain passé?[/quote]

"The days" cannot be "passé". The days might be passed. GNU might be passé.

(and while I've let my inner pedant off its leash, I should point out that it should be "ARE the days", not "is the days")

Is it so hard to expect competence in English from the summary authors? I guess so.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>