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.

5 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. Re:Success? by mmkkbb · · Score: 5, Interesting

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

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

  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
  5. Re:Depends... by joe_bruin · · Score: 5, Interesting

    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.