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

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

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

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?

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

Nice

[Jorl17]

I like LLVM, but I love 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...

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

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

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

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

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

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

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

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

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

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

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

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?

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

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.

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