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.
New Project, not feature complete (Score:5, Insightful)
Re: (Score:3, Informative)
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
Re: (Score:2)
Re: (Score:2)
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.
Success? (Score:2)
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)
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)
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)
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: (Score:2)
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
Re: (Score:2)
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)
is the days of GNU as the mainstream free and open development toolchain passé?
Does I not understand some grammatical concept here?
Re: (Score:2)
How often does debugger speed matter? (Score:5, 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.
Re: (Score:2, Insightful)
Re:How often does debugger speed matter? (Score:5, Insightful)
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.
Re: (Score:2)
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
Re: (Score:2)
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
Re:How often does debugger speed matter? (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.
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.
Re:How often does debugger speed matter? (Score:5, Insightful)
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.
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.
Re: (Score:2)
"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
Re:How often does debugger speed matter? (Score:4, Informative)
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.
Re: (Score:2)
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).
Re: (Score:2)
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.
Re: (Score:2)
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)
Re:How often does debugger speed matter? (Score:5, 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.
Re: (Score:2)
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.
Re: (Score:2)
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)
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
Definitely. The more options, the better.
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:2)
So they'll become part of the next standard ;-)
Re: (Score:3, Insightful)
Nice (Score:2, Interesting)
Depends... (Score:5, Insightful)
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)
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
you think gcc is slow? try the sun or aix compilers!
Re:Depends... (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.
Re:Depends... (Score:4, Interesting)
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.
Re: (Score:2)
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)
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)
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.
Re: (Score:2)
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.
gcc is seriously broken (Score:3, Insightful)
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)
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)
Unlike GCC, outsiders can successfully provide patches and bug repor
Re: (Score:2)
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)
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)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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."
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
> This latest trend of GPL projects relicensing BSD code so the BSD project can't use the improvements makes me seethe those.
But they _chose_ to say that BSD code can be relicensed in such a way. If they wanted to keep the improvements then they should have chosen the LGPL.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
I thought that relicensing BSD stuff as GPL was totally ok by BSD people, especially if it is equivalent of making it proprietary. Or am I missing something?
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Re:Depends... (Score:5, Insightful)
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.
Re: (Score:2)
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
Re: (Score:2)
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?
Re: (Score:2)
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.
Re: (Score:2)
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)
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.
Re: (Score:2)
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: (Score:2)
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.
Re:Depends... (Score:5, Informative)
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)
Re: (Score:3, Informative)
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.
Re: (Score:2)
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)
Re: (Score:2)
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.
What part of Free do you not grok? (Score:3, Interesting)
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
Re: (Score:2)
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?
Re: (Score:2)
Seriously, say you see a salvation army volunteer on the street and you contribute $5, feeling prett
Re: (Score:2)
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.
Re: (Score:2)
Fast? Why do I care if the debugger is fast? (Score:3, Insightful)
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.
Re:Fast? Why do I care if the debugger is fast? (Score:4, Insightful)
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.
Re:Fast? Why do I care if the debugger is fast? (Score:4, Informative)
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: (Score:2)
Oh sure, but there are cases where recompiling is not an option.
Re: (Score:2)
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.
Re: (Score:2)
2 girls 1 handkerchief?
Re: (Score:2)
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
Possible? (Score:2)
Using it already thanks.
So what? (Score:3, Insightful)
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.
Re: (Score:2)
It doesn't do all of c++ yet, it doesn't do i386, it doesn't do debugging on anything but OSX. You're a bit too quick to call LLVM superior when it's only benefits are theoretical or yet to be done.
Re: (Score:2)
I use LLVM on a daily basis. It's great.
I also talk a lot with some compiler-developers working/having worked for both GCC and LLVM, and I hear what they're saying.
I've also myself attempted to dwelve into the code-base of GCC, and well, you won't hear me argue against a clean new take on compilers from a fresh C++ codebase.
LLDB in particular however, may BECOME another piece in the puzzle, but it's really to immature to say.
Re: (Score:3, Informative)
"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: (Score:2)
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.
Re: (Score:2)
You don't HAVE to do anything, you can simply fork the code and tell the FSF to get lost. When your superior version of GCC gains support everyone will use that instead.