Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
GNU is Not Unix Programming

New LLVM Debugger Subproject Already Faster Than GDB 174

Posted by timothy
from the pop-will-eat-itself dept.
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.
This discussion has been archived. No new comments can be posted.

New LLVM Debugger Subproject Already Faster Than GDB

Comments Filter:
  • by ustolemyname (1301665) on Thursday June 10, 2010 @02:40PM (#32526992)
    So maybe a better way of putting it is "not yet as slow"
    • Re: (Score:3, Informative)

      by c++0xFF (1758032)

      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 tha

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

  • 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? (Score:5, Interesting)

      by mmkkbb (816035) on Thursday June 10, 2010 @02:46PM (#32527072) Homepage Journal

      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: (Score:3, Informative)

      by Gerald (9696)

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

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

    • Re:Success? (Score:5, Informative)

      by mini me (132455) on Thursday June 10, 2010 @03:48PM (#32528026)

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

    • by ld a,b (1207022)

      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

      • by CAIMLAS (41445)

        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.

  • Grammar (Score:2, Funny)

    by Anonymous Coward

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

    Does I not understand some grammatical concept here?

  • by pthisis (27352) on Thursday June 10, 2010 @02:46PM (#32527076) Homepage Journal

    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: (Score:2, Insightful)

      by Incster (1002638)
      Debugger speed only matters whey you are debugging. Anything that significantly speeds up the edit/compile/debug cycle is very welcome.
      • by pthisis (27352) on Thursday June 10, 2010 @03:31PM (#32527746) Homepage Journal

        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.

        • by stripes (3681)

          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

    • by c++0xFF (1758032) on Thursday June 10, 2010 @03:04PM (#32527302)

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

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

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

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

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

      • by pthisis (27352) on Thursday June 10, 2010 @03:36PM (#32527830) Homepage Journal

        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.

        • by Shinobi (19308)

          "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

          • by TheRaven64 (641858) on Thursday June 10, 2010 @05:17PM (#32529160) Journal

            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.

            • by c++0xFF (1758032)

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

            • by Shinobi (19308)

              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.

              • by jonwil (467024)

                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)

    • by samkass (174571) on Thursday June 10, 2010 @03:07PM (#32527346) Homepage Journal

      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.

      • by menkhaura (103150)

        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.

        • by Halo1 (136547)

          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. It'll also make open source code better, as gccisms get cleaned out of code.

      • by pthisis (27352)

        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

    • Re: (Score:3, Insightful)

      by TheRaven64 (641858)
      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
  • Nice (Score:2, Interesting)

    by Jorl17 (1716772)
    I like LLVM, but I love TenDRA [wikipedia.org].
  • Depends... (Score:5, Insightful)

    by fuzzyfuzzyfungus (1223518) on Thursday June 10, 2010 @02:50PM (#32527146) Journal
    "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... (Score:4, Insightful)

      by should_be_linear (779431) on Thursday June 10, 2010 @03:01PM (#32527254)
      if they achieve +10% of avg. performance against gcc (not gdb!) on AMD64 and/or ARM platform, everyone will start using it pretty soon. Until then it cannot replace gcc. Unless compiler is in some way seriously broken, its only important characteristic is performance of generated code.
      • by mmkkbb (816035)

        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

        • by c++0xFF (1758032)

          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

        • by SkunkPussy (85271)

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

      • Re:Depends... (Score:5, Interesting)

        by joe_bruin (266648) on Thursday June 10, 2010 @03:50PM (#32528044) Homepage Journal

        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... (Score:4, Interesting)

          by Halo1 (136547) <jonas.maebe@elis.[ ]nt.be ['uge' in gap]> on Thursday June 10, 2010 @04:58PM (#32528934) Homepage

          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.

        • by smcdow (114828)

          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: (Score:3, Insightful)

            by coredog64 (1001648)

            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... (Score:5, Informative)

          by LingNoi (1066278) on Friday June 11, 2010 @12:05AM (#32531984)

          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 [agner.org] and intentionally de-optimises your code? Yeah 10% faster*

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

          • by Shinobi (19308)

            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.

      • 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
    • Re: (Score:3, Insightful)

      by 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: (Score:2, Informative)

      by Renegade88 (874837)
      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 repor
      • 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

        • Re: (Score:3, Insightful)

          by Renegade88 (874837)
          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
          • Re: (Score:3, Informative)

            by Jah-Wren Ryel (80510)

            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.

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

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

                    • 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
        • by dgatwood (11270)

          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

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

            • 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
      • Re:Depends... (Score:5, Insightful)

        by fuzzyfuzzyfungus (1223518) on Thursday June 10, 2010 @03:23PM (#32527594) Journal
        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.
      • by rahvin112 (446269)

        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

        • by abigor (540274)

          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?

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

        • by stripes (3681)

          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: (Score:3, Informative)

        by c++0xFF (1758032)

        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.

        • by Halo1 (136547)

          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

    • Re:Depends... (Score:5, Informative)

      by samkass (174571) on Thursday June 10, 2010 @03:04PM (#32527308) Homepage Journal

      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: (Score:2, Interesting)

        by cheesybagel (670288)
        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: (Score:3, Informative)

          by kthreadd (1558445)
          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: (Score:3, Informative)

          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.

          • 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: (Score:2, Interesting)

        by 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.
      • 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
      • by LingNoi (1066278)

        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.

        • Any action used to subvert the GPL resulting in truly free software is a good intention in my book.
  • by Technomancer (51963) on Thursday June 10, 2010 @03:02PM (#32527276)

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

    • by mmkkbb (816035) on Thursday June 10, 2010 @03:06PM (#32527336) Homepage Journal

      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.

      • by c++0xFF (1758032) on Thursday June 10, 2010 @03:44PM (#32527972)

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

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

        • by mmkkbb (816035)

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

          • by c++0xFF (1758032)

            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.

    • 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

  • Using it already thanks.

  • So what? (Score:3, Insightful)

    by rawler (1005089) <.moc.liamg. .ta. .nossleakim.kirlu.> on Thursday June 10, 2010 @04:34PM (#32528646)

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

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

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

Riches: A gift from Heaven signifying, "This is my beloved son, in whom I am well pleased." -- John D. Rockefeller, (slander by Ambrose Bierce)

Working...