New LLVM Debugger Subproject Already Faster Than GDB

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.

Comments

New Project, not feature complete

[ustolemyname]

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

Re:New Project, not feature complete

[drdrgivemethenews]

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

Re:New Project, not feature complete

[c 0xFF]

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

[ustolemyname]

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

Re:New Project, not feature complete

[buchner.johannes]

Maybe in a few years we will have several C compilers, and OSS maintainers have to fix (or accept fixes) that make the packages compilable (like browsers).
That will probably lead to better code (more security warnings, for one; better portability).

Come to think of it, there isn't really a system where all the make warnings/errors on the user end are sent back to the project and connected to resolutions (or stimulating patches). That'd be useful.

Re:New Project, not feature complete

[Anonymous Coward]

One would hope that browsers becomes more like compilers rather than the other way around.

Success?

[Bill_the_Engineer]

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?

[mmkkbb]

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?

[Gerald]

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, which is nonexistent in the GNU toolchain.

Re:Success?

[mini me]

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?

[Anonymous Coward]

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?

[maxume]

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

Re:Success?

[ld a,b]

Unlike GCC as a compiler, GDB really sucks as a debugger. It is a source player, nice for high level "debugging", but as soon as you try to follow code that cannot be statically extracted from the ELF and DWARF data you are left with a blinking light and a feature-set comparable to the APPLE I MONITOR.

I doubt LLDB will fix the latter, but it'll probably wipe GDB's ass as a source player because Clang already gets a lot more and better errors and warnings than GCC.

Still, supported platforms: Mac OS X x86 and amd64. So it isn't really here yet. No need to worry.

Re:Success?

[CAIMLAS]

Unlike GCC as a compiler, GDB really sucks as a debugger.

I can't speak for GDB, but from what I understand of GCC, it isn't all that great, either. I've heard that compared to, say, the compiler in Visual Studio, it produces some pretty slow binaries. And I've witnessed how, compared to Open64, how vastly inferior the binaries are in terms of execution speed.

Re:Success?

[Brane2]

Can you give an example ?

I tried Open64 with bzip2 and result was about the same execution speed as with gcc-4.3 ...

Re:Success?

[Anonymous Coward]

Well, code generation is tricky. And as many say, GCC was deliberately made a mess and thus many people and companies that could help simply don't. Still, what GCC lacks in optimization it makes up for in architecture support.

In the end, a compiler that is able to generate correct code and errors/warnings is a good compiler.

If GCC is the Daewoo of compilers, GDB is the Rickshaw(driver not included) of debuggers.

Re:Success?

[CAIMLAS]

It was a Gentoo system on AMD64 (ie not Intel - Athlon 64 x2 4200 with 2GB RAM). Much of the system, including X, KDE4, was rebuilt using O64. Observed performance was approximately a third faster than previously: faster X/KDE start as well as perceived "snappiness".

Grammar

[Anonymous Coward]

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

Does I not understand some grammatical concept here?

Re:Grammar

[kthreadd]

Thanks for the heads up. I appreciate it.

I'm I the only one

[Anonymous Coward]

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

Re:I'm I the only one

[Anonymous Coward]

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

Everybody please enjoy your penisy GNU stories now.

How often does debugger speed matter?

[pthisis]

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?

[Incster]

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?

[c 0xFF]

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?

[samkass]

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?

[pthisis]

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?

[pthisis]

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?

[David Gerard]

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?

[menkhaura]

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?

[bonch]

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?

[Shinobi]

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

[Halo1]

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/ (bottom two sub-entries in the left frame, check the SPECINT/SPECFP2000 score graphs)

Re:How often does debugger speed matter?

[TheRaven64]

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

Re:How often does debugger speed matter?

[TheRaven64]

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?

[pthisis]

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?

[TheRaven64]

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.

Re:How often does debugger speed matter?

[David Gerard]

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

Re:How often does debugger speed matter?

[c 0xFF]

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?

[Anonymous Coward]

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?

[Anonymous Coward]

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?

[stripes]

Debugger speed matters when you debug something large. I frequently have things where gdb takes close to a minute to load symbols.

Debugger speed also matters for things like watchpoints. Watchpoints in gdb are so slow I almost never use them (like not at all this year, and maybe once last year).

Last time I have fast watch points (which was 1991, I had a CPU emulation box that ran at the full 68k speed with up to 8 watchpoints, and could dump the prior 200 cycles of bus activity and internal register state) I used them a LOT. Like three times a week.

A faster debugger might also make integrating a debugger and a unit test environment simpler. "run this code, fail the test if function X is not called, or if function Y is called, or if function Z isn't called exactly 8 times..." As it is there are some tests that can't be written using the API, you need scaffolding, and that scaffolding can introduce or suppress it's own errors...

Re:How often does debugger speed matter?

[Shinobi]

My particular horror stories about GCC involve working on, among other things, IA64. And in the HPC field, even on x86 you're better off with other compilers, if nothing else because they have better standards support.

The reason I brought up merely the back-end horror and pain of GCC internals is because that was the context. I don't do much work on the front-end side in comparison, however I do know it's painful too after swapping stories with colleagues who work more on that side of things.

Re:How often does debugger speed matter?

[David Greene]

It's not just a fast debugger. Imagine having a fully-capable C++ parser in your debugger. This could potentially run rings around gdb for debugging C++.

To me, the most interesting possibility is the LLVM JIT. Right now it's very easy to peg gdb at 100% utilization by putting a conditional breakpoint at the wrong place. Now imagine the breakpoint condition being JITed into executable code and linked directly into the program being debugged.

I am still somewhat skeptical about libc++, but lldb potentially adds a lot to the table.

Re:How often does debugger speed matter?

[Anonymous Coward]

It depends on the size of the application you’re working on. On large C++ projects the amount of time that gdb spends grubbing around for symbols and the resulting memory use can make debugging a frustrating experience.

Re:How often does debugger speed matter?

[jonwil]

I fell the pain of dealing with the GCC back-end.
I was once trying to implement support for the Windows thread-local-storage support (provided by __declspec(thread) on MS compilers) into windows GCC and gave up after being unable to understand the way the middle and back end parts worked and how to get it to emit the correct instructions (which reference the FS or GS register IIRC)

Re:How often does debugger speed matter?

[TheThiefMaster]

I assume by watchpoints you mean memory read/write traps. I use them all the time in Visual Studio. Guess it's a faster debugger than gdb.
Data breakpoints (memory write traps) are an absolute godsend. As far as I can tell they're hardware supported.
Conditional breakpoints are the slow ones, mostly if used in an inner loop of something that runs too many times to be sensible. But the fact that they can work with almost any c++ (to the point of calling virtual functions on classes) is incredible. The only annoying restriction is that you can't use anything that's been inlined in the actual executable.

Re:How often does debugger speed matter?

[GooberToo]

Data breakpoints (memory write traps) are an absolute godsend.

I used to think so too - but not with the GCC tools. Its so slow that I just don't do it any more. I now almost exclusively use some form of logging. Any debugger which allows for the use of write traps again is absolutely a big improvement.

Between the speed of symbol loading and use of several advanced features, debugging with gdb is frequently not an option worth consideration. I sure hope this debugger changes all that.

Nice

[Jorl17]

I like LLVM, but I love TenDRA.

Re:Nice

[kescom]

Why TenDRA?

Re:Nice

[Jorl17]

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

[fuzzyfuzzyfungus]

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

[should_be_linear]

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

[Anonymous Coward]

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

[Renegade88]

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

[mmkkbb]

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

[samkass]

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

[cheesybagel]

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

[Anonymous Coward]

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

Re:Depends...

[cheesybagel]

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

[Jah-Wren Ryel]

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

[fuzzyfuzzyfungus]

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

[Anonymous Coward]

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

[rahvin112]

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

[c 0xFF]

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

[c 0xFF]

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

[abigor]

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

[Jah-Wren Ryel]

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.

Re:Depends...

[joe_bruin]

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

[Jah-Wren Ryel]

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

[Renegade88]

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

[Anonymous Coward]

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

[kthreadd]

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

[SteeldrivingJon]

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

[AresTheImpaler]

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

[Jah-Wren Ryel]

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

[losinggeneration]

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

[Anonymous Coward]

How about the platform that matters, x86?

Re:Depends...

[Renegade88]

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

[ToasterMonkey]

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

[bonch]

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

[Halo1]

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

[Renegade88]

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

[bonch]

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.

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

[Anonymous Coward]

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

Re:Depends...

[bonch]

Xcode 4 is LLVM by default.

Re:Depends...

[Halo1]

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

[Anonymous Coward]

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.

Re:Depends...

[smcdow]

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

[Haeleth]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

[coredog64]

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

[SkunkPussy]

you think gcc is slow? try the sun or aix compilers!

Re:Depends...

[Jah-Wren Ryel]

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.

Which was fuzzyfuzzyfungus's point in the first place. Your castigation of him was misdirected at strawmen.

Re:Depends...

[Jah-Wren Ryel]

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

Hardly a hypothetical. I even cited the example of Wine in the very same post you responded to.

Do you really think all the engineers working on LLVM are doing it for free?

Re:Depends...

[dgatwood]

Nope, but if those proprietary forks compete against anyone doing work on the main branch

Stop right there. The vast majority of corporate contributions to open source involves companies using the open source project for a small portion of a much larger product. From the work of Apple and other companies on Clang/LLVM to the way TiVo and home router manufacturers use the Linux kernel, open source is almost always used as the basis for a significantly bigger product. The cases where an open source project and a commercial project are actually competing is almost nonexistent (with a few fairly visible exceptions like MySQL and CodeWeavers), and even then, most of the companies are good citizens and contribute fixes back to the open source project or fork and create a new open source project (e.g. WebKit).

For every case where a private fork competes with a free and open fork, I can list a hundred cases of an open source tool being used as a portion of a larger product. Thus, for every case where GPLv3 discouraged corporate privatization of the code, it discouraged a hundred companies from using the code in a way that would not compete with and potentially harm the open source project....

Re:Depends...

[simcop2387]

That and the good IR allows llvm to do the translation to the local architecture at "run" time (execution time anyway) so that you can have a single linked binary that is able to be run on multiple architectures with little fuss. What i'm not sure about is if ELF can handle so called "fat" binaries that would have the llvm IR and a few common architectures too.

Re:Depends...

[Jah-Wren Ryel]

Stop right there.

Back that truck up. Do you see the part in the original post that said, "I would hope that that doesn't happen; but the potential exists?" Good thing we weren't talking about absolutes.

Thus, for every case where GPLv3 discouraged corporate privatization of the code, it discouraged a hundred companies from using the code in a way that would not compete with and potentially harm the open source project....

Which is, of course, irrelevant to the goals of the GPL. Those being the freedom of the end user.

Re:Depends...

[stripes]

Ok, so there were no significant "give backs" from MS, but on the other hand they didn't start out with some form of mutant TCP/IP that required the rest of the internet to bend over backwards to sort of interoperate with. So that is still a win in my book.

Re:Depends...

[Anonymous Coward]

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.

The fact that the overwhelming majority of dollars coming into free-software based companies is for GPL licensed code should be spell-breaking to the BSD crowd. But, this somehow reinforces belief, similar to telling a theist that his Bible is made-up fiction.

Its easy to license BSD when your own money isn't on the line.

Re:Depends...

[Anonymous Coward]

This latest trend of GPL projects relicensing BSD code so the BSD project can't use the improvements makes me seethe those.

Like that's even comparable to relicensing BSD code to be proprietary and keeping the improvements completely unavailable to anyone.

Relicensing of any sort, GPL or otherwise, certainly doesn't keep "code away from the author." You obviously meant "keep changes to the code away from the original author" - which is only a side-effect of not being a tight-ass about the GPL as all that the GPL requires is that code changes be made to the end user - there are zero requirements to feed them back upstream. If it's not even mentioned in the GPL you really can't claim that it is important to GPL advocates. It is no more important to GPL advocates than it is to BSD advocates. If you sincerely want to convince people of the errors of the GPL you should be able to accurately delineate them rather than hit them with red herrings.

Re:Depends...

[Anonymous Coward]

Psssh, they need to be taught what REAL trolling is.

TROLL ON

Re:Depends...

[LingNoi]

Intel's ICC compiler produces code that is more than 10% faster

You mean the same Intel compiler that detects if you're using an AMD processor and intentionally de-optimises your code? Yeah 10% faster*

* As long as you're using an Intel processor to compile.

Re:Depends...

[Renegade88]

I'm not sure what that means. Pretty much any time LLVM or LLVM subprojects come up, a bunch of GPL'ers start with, "it's a nice little project, too bad it doesn't have a copyleft license.". Obviously GPL'ers want the copyleft license to help them achieve RMS' dream of 100% "Free" software and BSD just gets in the way. At this point, we shouldn't be discussing the license and just assume the authors that choose the license in the first place knew exactly what they are doing, and the future contributers know and ACCEPT the ramifications of using the license.

Re:Depends...

[Renegade88]

It is not a red herring. For a BSD project, relicensing an improvement as GPL is equivalent to making it proprietary. Only it's worse, because it's done with malice. The GPL jerk who did this obviously has the option to leave the code and the modification the original license, but intentionally chose to prevent the author from legally being able to use the code.

People that do this (and support this) are punks.

The obvious recent example was the relicensing of BSD drivers from OpenBSD. When given the opportunity to correct an "honest" mistake, the punk steadfastly refused even with the FSF asking him nicely to reconsider (knowing the backlash it could cause) so clearly it's important to some of these advocates.

Re:Depends...

[Renegade88]

Right, which is why GPL is increasingly becoming a dirty word. With V3 and interpretation of what GPL actually means, people are getting educated (well, somebody has to paraphase V3 because nobody other than a lawyer can actually understand what's written in that document) and with that knowledge are realizing that the terms aren't acceptable. It's the small part of a big project scenario that I really hate -- GPL says the whole damn thing is a derivative work, even if it's 0.05% of the overall. It's okay though. Any decent GPL-only functionality will be replaced eventually by one friendly to BSD projects and commercial interests. It's not surprising to me at all that LLVM is generating lots of interest from commercial entities and progressing rapidly because of it.

Re:Depends...

[Jah-Wren Ryel]

I'm not sure what that means.

It means you jumped on his ass, called him a fanatic and proceeded to righteously refute something he didn't say.
Kind of like...

Pretty much any time LLVM or LLVM subprojects come up, a bunch of GPL'ers start with, "it's a nice little project, too bad it doesn't have a copyleft license."

Re:Depends...

[Jah-Wren Ryel]

Whatever dude. For someone who started off accusing other people of being a fanatic you have demonstrated a remarkable affinity for a single track.

Re:Depends...

[LingNoi]

The GPL exists to get another projects to change their license.

The GPL exists to stop people taking what someone else has written and not giving away the source code with the binary like the author intended. Anyone who has started a GPL project hasn't done it to convert anyone to their cause, they just want a way for their intentions to be enforced when it comes to the things they've created.

If you don't like that you can simply keep your changes private and not redistribute any GPL code. If you still don't like that then you don't have to use their code at all (hence why we have BSD in the first place).

This latest trend of GPL projects relicensing BSD code so the BSD project can't use the improvements makes me seethe those.

Why would this annoy you? You should be celebrating over the freedom the BSD license gives developers to allow such a thing.

Obviously the BSD license isn't for you because you don't believe in the freedoms that the BSD license grants developers. Perhaps you should consider updating the BSD license to better enforce your intentions when redistributing code rather then whining about it.

Re:Depends...

[LingNoi]

The only thing that has made Apple contribute large resources to LLVM is because they don't want to use the GPLv3 in GCC which is why they're rushing to get LLVM as a workable replacement. That doesn't mean LLVM is bad however I don't believe Apple ever had good intentions to start out with.

Re:Depends...

[JohnFluxx]

> This latest trend of GPL projects relicensing BSD code so the BSD project can't use the improvements makes me seethe those.

But they _chose_ to say that BSD code can be relicensed in such a way. If they wanted to keep the improvements then they should have chosen the LGPL.

Re:Depends...

[Renegade88]

Any action used to subvert the GPL resulting in truly free software is a good intention in my book.

Re:Depends...

[Renegade88]

Who's backpedaling now, then? The GPL's stated desire to gobble up code they had nothing to do with is a big deal. It's pretty much the cornerstone of the license, and the basis for licensing readline as GPL and not the more logical LGPL. Protecting yourself against the viral invasion of GPL (both open-source and proprietary projects) is not fanatism, it smart on many levels.

Re:Depends...

[raynet]

I thought that relicensing BSD stuff as GPL was totally ok by BSD people, especially if it is equivalent of making it proprietary. Or am I missing something?

Re:Depends...

[Shinobi]

The Intel compiler is still faster than GCC, or any of the other competitors, which is why it is the default on AMD-based supercomputers owned by people/organizations that aren't retarded.

Re:Depends...

[Renegade88]

I think you are mincing words. He starts with "Since it is under a BSD-esque license,", and states a risk resulting from the license with the obvious implication that a copyleft license wouldn't suffer this perceived risk.

Again, why even make this statement unless you are trying to stir stuff up? By now, hopefully people know the pros and cons of each basic license type. You can apply this "concern" to any BSD project. Obviously some people believe it, great. They don't need to use or contribute to the project. The rest can, and will have to assume the "risk" that FFF is worried about.

Re:Depends...

[Renegade88]

Yes, you are missing something. In this case, the GPL'er removed the BSD license. You can't do that. You can't change the licence of the existing code because you aren't the copyright owner. You can add your own license to the code changes though (so part of the code is under one license and the rest under another). Obviously the part of removing the BSD license is illegal and had to be reversed. The part of having the modifications as GPL is not illegal, but morally questionable since it means that practically the original author can't use the code. Obviously he could, but then he would have to relicense the original code as GPL, so the modifications are, in effect, a poison pill.

Re:Depends...

[Renegade88]

To be clear, only the modifications can have a different license. The original code must stay under the original licence. However, if the modifier intentionally (and therefore maliciously) licenses his changes knowing that the original author can't use them, then he is a punk.
Is it legal? Yes.
Is it just? IMO, no.
Does it serve any purpose? Yes, it serves to make BSD advocates fear the GPL for good reason.
Can the BSD complain since they picked the license? Ultimately no. However, I think they are justified in painting GPL advocates as hypocrites in the highest order. They lock away code from BSD just as they claim close-source locks away improvements from them.

Re:Depends...

[Renegade88]

You can see my response to JohnFluxx below because it applies to your childish post too. Regarding the purpose of the GPL, that's actually the purpose of the LGPL. Perhaps you should take time to understand the ramifications and goals of your license better. I have contributed changes back to GPL and LGPL projects, btw. However, don't worry, people *are* taking the option to not use GPL code at all.

Re:Depends...

[petsounds]

Ironically, Adobe used LLVM for their ill-fated Flash -> iPhone project to take Actionscript bytecode and cross-compile it to ARM. "Do what I say, not what I do."

Re:Depends...

[JohnFluxx]

So what is the purpose in licensing as BSD instead of the LGPL if you're then going to complain about anyone that actually uses the difference between them.

Re:Depends...

[LingNoi]

Perhaps you should take time to understand the ramifications and goals of your license better.

Cool story bro but I think I know my own reasons for putting my code under the GPL you don't need to tell me why I did it or tell me I'm wrong.

Regarding the purpose of the GPL, that's actually the purpose of the LGPL

The LGPL is for libraries where you want to allow applications to be able to use them without having to use the same license.

My application isn't a library so the GPL is serving the purpose that I already stated quite well thanks. I know the licenses quite well already and seem to have a better understanding then you do.

You can see my response to JohnFluxx below because it applies to your childish post too.

You've called anyone that puts a project under the GPL a zealot that's out to convert the world yet you call my reasonable response childish.

Some people don't like their code being used in certain ways. Get over it dude.

The only one being childish and a zealot is you. You simply can't accept that not everyone agrees with your way of thinking and when people point out the flaw in your logic you simply attack them.

Re:Depends...

[Anonymous Coward]

Except you don't really care about truly free software (TM), you just care about anti-GPL. Otherwise you wouldn't have been complaining further up about using BSD code in GPL code but not about closed source forks.

It's better you stop talking, all you're doing is making the BSD community look bad.

Re:Depends...

[makomk]

In some fairly important cases, the Intel compiler is known to produce slower code than gcc -O0 on AMD processors. Their deoptimizations are as impressive as their optimizations.

Re:Depends...

[raynet]

Well, I was aware of the case where they removed the BSD license, which is a no-no. But I was thinking more generally and thought that the BSD developer doesn't care if his code is GPL'ed or put into some closed source app. In both cases the modifications are copyrighted to the new author and licensed under non-BSD license.

Re:Depends...

[Philip_the_physicist]

There is a project called FatELF: http://icculus.org/fatelf/
LLVM IR wouldn't be a valid internal format, but only because it hasn't got an ELF machine type (AFAIK, anyway), and the loader would probably need to be patched to run it in the appropriate VM if there is no native version available, but that shouldn't be too hard.

Another useful, although far more difficult, project would be a VM which uses (a probably modified version of) LLVM IR, combined with a security wrapper around POSIX library calls, to produce an alternative to Mono/CLR, JVM, and so on, but usable with virtually all languages.

Passe

[ultrabot]

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

[bonch]

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

Re:Passe

[Anonymous Coward]

Note that FreeBSD has just imported clang to FreeBSD head.

Fast? Why do I care if the debugger is fast?

[Technomancer]

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?

[mmkkbb]

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?

[Anonymous Coward]

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?

[c 0xFF]

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?

[losinggeneration]

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.

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

[Anonymous Coward]

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

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

[ceswiedler]

I'm guessing that one of the goals of this debugger is to allow embedding it in higher-level tools or scripts, meaning an IDE like KDevelop could load the debugger as a shard library and communicate with it through an API, instead of spawning a process and interacting with it via stdin/stdout. Similarly it could load the compiler and get access to the parsed symbol tree for a source file or library, so it could do more interesting things like tooltips, autocompletion, etc.

So, the 'visual overlays' for LLDB could theoretically be faster and more feature-rich than those for GDB.

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

[mmkkbb]

Oh sure, but there are cases where recompiling is not an option.

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

[c 0xFF]

Or very, very inconvenient. Debugging is an active process, so setting breakpoints is something I do constantly. Modifying code just to set a quick breakpoint isn't fun ... and then you have to do it again for the next breakpoint.

I didn't say it was a good option, but at least it's something.

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

[c 0xFF]

2 girls 1 handkerchief?

what about the code speed?

[Anonymous Coward]

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?

[SuperKendall]

Using it already thanks.

It limits what your debugger can do

[DLPierson]

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/ for details. The key point is that Parasight was fast enough to make tools like this useable.

Performance

[Anonymous Coward]

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

[SteeldrivingJon]

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

[Anonymous Coward]

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.

So what?

[rawler]

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?

[bonch]

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.

Re:So what?

[Anonymous Coward]

Performance is the slashdot summary key point, but if you look at the LLDB project goals page, better C++ and multithreading support is the main impetus of the project. Conclusion: don't rely on slashdot for anything. If a slashdot story told me the sky were blue, I'd have to go outside and check...

Re:So what?

[ewertz]

I guess you haven't been reading the entry to which you're replying.
Apparently to you the last piece of the puzzle is that last 10% that takes 90(0-00)% of the effort. So, as long as you number these days with at least four digits, you might get some agreement. Otherwise your argument only holds any water when talking about the x86 bladder, as has been pointed out numerous times already.

Re:So what?

[LingNoi]

It doesn't do all of c++ yet, it doesn't do i386, it doesn't do debugging on anything but OSX. You're a bit too quick to call LLVM superior when it's only benefits are theoretical or yet to be done.

Re:So what?

[rawler]

I use LLVM on a daily basis. It's great.

I also talk a lot with some compiler-developers working/having worked for both GCC and LLVM, and I hear what they're saying.

I've also myself attempted to dwelve into the code-base of GCC, and well, you won't hear me argue against a clean new take on compilers from a fresh C++ codebase.

LLDB in particular however, may BECOME another piece in the puzzle, but it's really to immature to say.

Re:So what?

[Guy Harris]

it doesn't do i386

The LLDB Homepage claims otherwise:

LLDB is known to work on the following platforms, but ports to new platforms are welcome:

• Mac OS X i386 and x86-64

Who needs debuggers...

[Anonymous Coward]

...when there's printf?

Trying to be clever in the summary, and failing

[Anonymous Coward]

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

gcc is seriously broken

[Gary W. Longsine]

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

What would really kill GNU toolchain

[Anonymous Coward]

LLDB won't kill the GNU toolchain. What would kill GNU toolchain is the FSF's crazy meddling:

* Why does the GCC steering committee has to ask FSF for approval of technical decisions like switching to C++, or creating the plugin system? Especially as the FSF's resistance to frontend-backend separation hampered Free software, and led to LLVM in the first place.

* Why does anyone trying to contribute to GCC have to sign copyright assignment to FSF, when even large projects like Linux (or more comparably LLVM) avoid this? Note that it's not nearly as simple as downloading a form and signing it. One has to fill a form in order to ask to be sent a copyright assignment form in the mail from the FSF.

* Why after creating all these troubles for contributers, did the FSF avoid suing Sun for GCCfss? Apparently in spite of all the rhetoric, large companies can infringe at will.

As an external observer of GCC, I don't think it can really recover until the FSF lets the leash go and let the steering committee manage the project.

Re:What would really kill GNU toolchain

[OrangeTide]

Sun has given out the source for GPL parts of gccfss for quite a while, including any parts that links to GPL parts. And therefor complies with the license. But nobody wants the hacks, at least not FSF, because it essentially lets different backends be plugged into GCC.

Re:What would really kill GNU toolchain

[LingNoi]

You don't HAVE to do anything, you can simply fork the code and tell the FSF to get lost. When your superior version of GCC gains support everyone will use that instead.

What part of Free do you not grok?

[Gary W. Longsine]

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

Free. Not encumbered in any way. No bullshit pseudo libertarian crap about distinctions between free beer and speech. The entire LLVM project is completely bloody f'ing free . It's a damn sight more free than the almost but not quite really free gcc.

LLVM is an entirely free and open source code to a complete compiler, several front ends, several back ends, optimization code. Better than that, it's all implemented as libraries you can easily compile in and link with your code. And a standardized Intermediate Representation. And today they added a free debugger under the same entirely free and entirely open terms. For free.

Go troll elsewhere, GPL freak.

Re:What part of Free do you not grok?

[Jah-Wren Ryel]

So, you are disputing the claim that "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." ?? That apple really has released every part of their internal LLVM project? That they have no proprietary-only parts?

Or, are you just knee-jerking because you can't quite grasp the discussion that the adults are having?

Re:What part of Free do you not grok?

[Renegade88]

I don't know how anybody can refute or dispute the claim if its internal to Apple. However, it doesn't matter. Not only because they are allowed to legally and morally, but because LLVM wouldn't exist in the state that its in without their financial and developer support. Some of us choose to be grateful for what was contributed in good faith rather than demanding that a benefactor give everything he has.

Seriously, say you see a salvation army volunteer on the street and you contribute $5, feeling pretty good about yourself and then the volunteer demands that you open up you wallet and dump it all the bucket? I'm guessing the next time around you wouldn't give that ingrate a dime.

Re:What part of Free do you not grok?

[Anonymous Coward]

I don't know how anybody can refute or dispute the claim if its internal to Apple.

They can't refute it because apple has made numerous public presentations on their OpenGL backend which they have not released. I don't ask questions like that when I don't already know the answer. Its a more subtle way of calling someone a total moron.

Some of us choose to be grateful for what was contributed in good faith rather than demanding that a benefactor give everything he has.

The point being that, just like with OSX, apple only open-sources stuff they think won't possibly result in direct competition and they do it to get free engineering from others.
Apple would have had to do a lot more work if they had keep LLVM completely in house. That anyone else benefits as an unintended side-effect is true but irrelevant - the point is that apple is making explicitly cynical use of the BSD licensing terms.

I expect that you will now choose to fly your freak flag high with more willful misunderstanding of the subject. Have at it Don Quixote, I'm out and won't even see your response.

Clang/LLVM is becoming relevant in FreeBSD too

[cpghost]

FreeBSD is currently moving (slowly) towards Clang/LLVM with their ClangBSD subproject. They've just imported clang into the base system of FreeBSD (-CURRENT), and clangbsd is on its way.

Licensing

[DrYak]

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.

There are still problems around the "freedom" part, as LLVM is using BSD-style licensing, authorising proprietary forks. Whereas GCC uses GPL licensing.

Thus there exists a risk that some innovation gets lost in proprietary forks where your freedom to hack won't be preserved.

Re:Licensing

[joe_bruin]

There are still problems around the "freedom" part, as LLVM is using BSD-style licensing, authorising proprietary forks. Whereas GCC uses GPL licensing.

You're right, it doesn't solve freedom the problem for all people, but for many it does. And for some that were afraid to touch GPLv3 code, LLVM offers more freedom. So, there are trade-offs.

Not yet, not anytime soon.

[DrYak]

GCC's days really are numbered, and this is one of the last pieces of the puzzle.

No, GCC's days are not numbered. At least not as long as LLVM only runs on/targets for/and compiles, the vast amount of supported platforms, processors, operating systems and languages that GCC supports, in a completely free(dom) manner.

For now, LLVM seems to be mainly x86 focused, whereas GCC supports lots of architectures. GCC can run on systems even such as MS-DOS or even weirder, etc.

LLVM is BSD licensed, which means that in the embed world, bad thing can happen (small embed companies releasing back-end targeting their chip only as proprietary blobs running on older versions of windows)

the quick and the stupid

[epine]

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

That's kind of funny. I have a dark suspicion that Apple created LLVM *precisely* so that they could maintain a private fork concerning some premium technologies (OpenCL, GCD, H.264 all come to mind). Generally, however, maintaining a private fork is a PITA so it happens far less than GPL bigots promulgate. (Non bigots don't promulgate. That's how you tell.)

Why do you think Intel bought Kuck and Associates? To make it optimize their own code more better, or optimize someone else's code less better? KCC before it was Intelified used to really kick ass, *especially* on AMD.

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.

Well, the last time I reported a edge case error in template support for GCC, it was fixed within *two days* of receiving my report. I guess the response time depends on the nature of what you report. But you have a point. A comparable edge case bug that I reported on the R users mailing list was fixed in 15 minutes by one of the core developers, so GCC does kind of suck. There was a bug I used to follow on Ubuntu that was still in triage three years after filing and had hundreds of people following, as resolution slipped from one release to the next. It's hard to speak in generalities about these things.

Finally, to all those people who think that only the generated code speed matters, grab a brain! The rate limiting factor on software quality and complexity is the tooling ecology. For example, suppose some day Eclipse CDT adopts the LLVM C++ parser and error message components. If this advantage were to enable me to write more powerful algorithms, *even if* the generated code under LLVM was 10% slower than some other compiler, my superior solution would still kick ass.

If the tooling advantage of LLVM is *already* making it more productive to add complex optimization passes to LLVM, somehow I doubt that 10% penalty continues to exist much longer.

The most important feature in a compiler is making the software developer smarter and more efficient.

forcefully polymorphic

[epine]

That was a nice summary of the situation.

It's funny how little I care what goes on behind closed binaries. OTOH, having GPL poison pills floating around in what started out as a BSD project is a form of spam that really irritates me, because their existence is hard to ignore. The guts of binary blobs don't pollute your result sets on Google code search. If Google had the perfect algorithm to guarantee that when I search for information about a BSD project, the existence of GPL poison pills forked off that code base *never comes to my attention* (this includes filtering discussion threads debating the matter) then I would have no objection to the GPL punk behaving like a jack-off. It's his life.

Sometimes the GPL people sound like they've spent far too long listening to Tom Wait's "What's he building in there?" Some of my systems are binary-blob free, others aren't. I know my options and I'm happy with my choices. Mother nature didn't publish her source code for the first three billion years. Suddenly the word "freedom" is polymorphic in a strange new way. Hijacking what came before has *always* been a part of the GPL Kool-Aid. Now that we've forcefully opened up mother nature's source code, we discover that hijacking has been part of the Kook-Aid since forever. It's a strange world.

booster seat

[epine]

For me, it's the immaturity of Clang/LLVM that makes the project so damn impressive, like a three year old playing Bach's cello suites.

LLVM Project Blog: Clang++ Builds Boost!

Re:booster seat

[rawler]

Cool view. :)

Though, for Clang/LLVM, I'd say it's more of a 19-year old, with fresh ideas and a brilliant career ahead. It's not a three-year-old anymore, more like just came out of adolescence.

For LLDB, as of yet, the immaturity makes it only-osx-supported, and only for x86(-64). It's not really playing cello yet, although I would not be too surprised if it will soon.

Next generation toolchain

[Anonymous Coward]

I want a completely submersive experience when debugging. Tie llvm/lldb into the Quake engine, for example, and visualize objects, data, io, relationships. Place all debugger controls in the 3d realm, for example slider on a wall for off->slow->faster->fastest code execution, objects colored by type, with hue changes for derived classes, zoom in and out on objects, watch temporary objects be created from across the room. Memory/variable watch on the walls. And then someone can figure out how to put the UML stuff in, too. And 3d profiling visuals, maybe off in another room where I can have a setup that's optimized for visualizing profiling information.

Bad Summary

[Devil's Avocado]

Before you start yelling OMG FASTER WHO CARES??? you might want to read the fine article:

"""
WHY A NEW DEBUGGER?

In order to achieve our goals we decided to start with a fresh architecture that would support modern multi-threaded programs, handle debugging symbols in an efficient manner, use compiler based code knowledge and have plug-in support for functionality and extensions. Additionally we want the debugger capabilities to be available to other analysis tools, be they scripts or compiled programs, without requiring them to be GPL.
"""

This is about better code analysis and integration, not faster debugging.