Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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.

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.

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.

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

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.

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.

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.

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.

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

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 ann

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.

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.

"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

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.

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.

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)

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.

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.

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

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

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

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 w

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

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

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.

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?

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.

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.

Well, the gcc is seriously broken in at least two interesting ways, both of which are fixed by The LLVM Project:

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

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?

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.

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.

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 f

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.

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 k

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

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

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

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 ar

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 o

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 p

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

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.

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 oka

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.

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.

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 communit

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.

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 th

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.

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.

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.

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.

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.

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

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?

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 prett

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.

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.

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.

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

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.

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

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.