Slashdot Mirror

← Back to Stories (view on slashdot.org)

New LLVM Debugger Subproject Already Faster Than GDB

Posted by timothy on 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.

8 of 174 comments (clear)

  1. New Project, not feature complete by ustolemyname · · Score: 5, Insightful

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

  2. How often does debugger speed matter? by pthisis · · Score: 4, Insightful

    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.

    --
    rage, rage against the dying of the light
    1. Re:How often does debugger speed matter? by c++0xFF · · Score: 4, Insightful

      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.

    2. Re:How often does debugger speed matter? by samkass · · Score: 4, Insightful

      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.

      --
      E pluribus unum
    3. Re:How often does debugger speed matter? by pthisis · · Score: 4, Insightful

      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.

      --
      rage, rage against the dying of the light
    4. Re:How often does debugger speed matter? by pthisis · · Score: 5, Insightful

      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.

      --
      rage, rage against the dying of the light
  3. Depends... by fuzzyfuzzyfungus · · Score: 4, Insightful

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

    1. Re:Depends... by fuzzyfuzzyfungus · · Score: 5, Insightful

      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.