Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
GNU is Not Unix Programming

New LLVM Debugger Subproject Already Faster Than GDB 174

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

New LLVM Debugger Subproject Already Faster Than GDB

Comments Filter:
  • Re:Depends... (Score:2, Informative)

    by Renegade88 ( 874837 ) on Thursday June 10, 2010 @04:03PM (#32527292)
    Ah, a staple argument from GPL fanatics. No, your scenario is not realistic. Even if somebody makes a proprietary branch, that doesn't deprive anybody of the mainstream branch. Only GPL freaks are concerned about this. The rest of us realize that maintaining a private fork of a large project like this an enormous pain in the rear and it's much more convenient for the improving entity just to give the fix back and let project absorb it.

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

    Anyway, other major BSD-like projects don't suffer from private forks, and there's no reason to think LLVM will either.
  • Re:Depends... (Score:5, Informative)

    by samkass ( 174571 ) on Thursday June 10, 2010 @04: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:Success? (Score:3, Informative)

    by Gerald ( 9696 ) on Thursday June 10, 2010 @04:14PM (#32527470) Homepage

    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.

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

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

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

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

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

    by c++0xFF ( 1758032 ) on Thursday June 10, 2010 @04:35PM (#32527812)

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

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

  • by c++0xFF ( 1758032 ) on Thursday June 10, 2010 @04: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.

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

    by mini me ( 132455 ) on Thursday June 10, 2010 @04: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.

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

    by kthreadd ( 1558445 ) on Thursday June 10, 2010 @05:07PM (#32528282)
    As of Xcode 3.2 they give you the choice of four compilers. GCC 4.0, GCC 4.2, LLVM GCC 4.2 and LLVM Clang 1.0.2. The default compiler is GCC 4.2 due to compatibility reasons but it will likely change to Clang in future versions.
  • Re:Depends... (Score:3, Informative)

    by SteeldrivingJon ( 842919 ) on Thursday June 10, 2010 @05:07PM (#32528286) Homepage Journal

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

    by SteeldrivingJon ( 842919 ) on Thursday June 10, 2010 @05:13PM (#32528366) Homepage Journal

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

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

    by Jah-Wren Ryel ( 80510 ) on Thursday June 10, 2010 @05:20PM (#32528440)

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

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

  • by TheRaven64 ( 641858 ) on Thursday June 10, 2010 @06: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 Anonymous Coward on Thursday June 10, 2010 @06:55PM (#32529600)

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

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

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

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

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

    by LingNoi ( 1066278 ) on Friday June 11, 2010 @01: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.

All Finagle Laws may be bypassed by learning the simple art of doing without thinking.