I hope it replaces the notoriously hard to use gdb. I actually like doing things on the commandline and am used to using minimalistic tools like vim, but gdb's obscure commandline behavior makes it very hard for me to use it for any real project.

"step" to step, "backtrace" to get a backtrace, ...? Yeah, that's confusing.

"step" and "backtrace" of course being the only possible logical names for those functions. Not having memorized the gdb info pages, I would never mistakenly type in "next" or "over" or "in" or "stack" or "stackframe" or "frame" or...

So use a gui like Nemiver if you don't want to deal with a cli.

When you try to do complicated stuff it does get confusing. Like remembering the exact way you need to type out C++ method names (you need to put single-quotes in just the right places.)

Which version are you running?

I am on 6.8.50.20081120-cvs I seem to have auto completion (on tab)

It does have tab completion, but it doesn't work well. I think you need to open the quote to tab complete (in C++, using namespaces or class names), but it seldom does what you want.

I've seen this since about 6.7, I last used 7.1.

So basically they want to a debugger as good as gdb, but BSD licensed. I think if this actually matures into something decent, the competition will be good for both projects.

Sounds like 'better', being built around a set of libraries first, with the ability to write plugins/extension in a reasonable language like Python.

Most software written originally 20 years ago is going to seem crusty, and have issues in a field as young as computer science -- there are just better ideas and practices these days compared to when GDB was first started, not even considering licensing issues.

Compare the architecture of Airplanes between WWI and WWII to the modern Jet age -- and real software development is still young compared to Airplanes, so yeah, its competition, but as long as it develops into a successful project, I'd expect it to be quite a bit better than GDB in the long run.

Of the tangible features that they list as motivation:

- Build libraries for inclusion in IDEs, command line tools, and other analysis tools - gdb seems to have it http://sourceware.org/gdb/papers/libgdb2/libgdb_toc.html

- High performance and efficient memory use - I cant comment on how much of gdb's sluggishness in running programs is inherent in the problem, and how much is gdb being slow.

- Extensible: Python scriptable and use a plug-in architecture - gdb has it http://sourceware.org/gdb/current/onlinedocs/gdb/Extending-G...

- Excellent multi-threaded debugging support - GDB could be better - I wish it could stop threads individually, instead of all-stop then all-resume even on a single step. But IIRC there is a project to be able to do something like this eventually.

- Great support for C, Objective-C and C++ - Can't comment on objective-c, but the C++ support has gotten significantly better since GCC 4.5/GDB 7.0 with pretty printing of C++ data structures, and has been steadily improving over time handling C++ mangling.

- Retargetable to support multiple platforms - gdb naturally is widely ported - A remote protocol server, debugserver, implements Mac OS X debugging on i386 and x86_64. - gdb has it

I haven't seen anything that really improves on gdb yet. Maybe (hopefully) I'm wrong...

For "high performance GDB", see tracepoints, which act somewhat like DTrace probes.

It comes from Apple and is bsd-licensed. In this community, this passes for "enhancements" over gdb. Yes, this is a bitter comment about the HN community state of mind.

I think that's far too cynical. gdb is fine, but there is tons of room for improvement, and more competition in this area can only be a good thing. It is early days yet for LLDB, but it is a promising start.

I've yet to see any IDE/debugger setup on a Unixen that comes close to competiting with Visual Studio's debugging interface, as unfortunate as that is.

You're absolutely right. However lldb hasn't gone that far so we can't know for sure if it will ever be any better than gdb.

I'll admit easily that gcc messages/gdb debugging actually suck wind :)

Yeah, pesky entrepreneurs and their eye for opportunity.

Well, my company only works on gpl stuff and doesn't suffer any inconvenience from that. So I call bluff.

You're saying that being able to statically link a library into a commercial app has no business value to anybody because you are fortunate enough to have found a niche where you didn't need to. Your personal experience is enviable, but I don't see how it speaks to the general case.

Yes -- antirez who wrote Redis wrote linenoise, a replacement of the 20k lines of the old GNU readline in about 400 lines of C for only the 99.99% of users who are on VT100 terminals. http://github.com/antirez/linenoise

I just use "read" which is only one line of code, and has about as many features as linenoise.

readline is "bloated" because it actually does something.

GNU readline is a bit of a bloated monster but it gives many programs vi-mode. Like gdb.

Hopefully this replaces GDB, and good riddance.

GDB 7.1 is a great improvement over previous versions and has a lot of the features LLDB intends to have - better C++ support, better thread debugging, more accurate backtraces, and a Python scripting API - as well as some features that aren't on the LLDB roadmap yet, like tracepoints for debugging time-sensitive code and multi-program debugging. You should check it out if you're unhappy with an older version.

Hum, I'd rather wait and see first. What about the truckloads of tools built around gdb (ddd, etc)? And why this should be any better, because it comes from Apple?

This is my personal opinion, but the tools built around it either use the gdb protocol which I'm sure LLDB will be implemented to speak, or tools that I don't care about (like DDD you mentioned.. it was just a pain to use).

I don't really dislike gdb per se, and it worked well enough for the tasks I used it for, but I just have a personal distaste code conventions of gdb, gcc and other huge GNU projects. I tried spelunking around gdb source to get at some OS X-specific features and tried adding simple instrumentation to GIMPLE trees in gcc's implementation, and both experiences left me with a negative opinion of GNU coding conventions and showed both projects' age. Looking at LLVM source and following their mailing lists is anything but, showing clear direction and clean implementation. I'm not a compiler guy by any stretch of the imagination, but LLVM felt very well-architected and modern.

Apple sponsored LLVM after I started following it, so while it's true that they are behind it, it has very little to do with my respect for it.

Apple employs a few (more than 1?) LLVM people, but it's hardly an Apple project by any means.

LLVM is a substantial and fantastic project. At the basis, it's a compiler backend in-a-box. Additional projects, like clang and this, are providing a modern compiler platform for us, finally. gcc & friends have made great advances, relative to other compilers, but they all do suck.

It's been 12 years and I still can't use C++ in a debugger without jumping through stupidity. It's literally easier to look at a type definition and read the memory out of a hex dump than go through 16 dropdowns of BS subtype definitions.

> Apple employs a few (more than 1?) LLVM people, but it's hardly an Apple project by any means.

They employ around two dozen LLVM developers, comprising half to two-thirds of the regular committers.

Oh wow.

I've found the Visual Studio debugger to be very nice, actually. It shows STL classes in an intelligible way, and the IDE integration is (as expected) excellent. Unfortunately OSS alternatives are still a lot less intuitive, and VS is stuck to Windows.

I was actually talking about the VS debugger. If you get even a little fancy with templates & metaprogramming, the whole thing is just terrible.

Any news on how much progress this is getting? Or a more top-level page, with more than (private-view-only) mailing list links? I'd love a decent competitor to GDB.

I would say that gdb can never be as good as lldb can be, simply for C++ expression parsing (unless they integrated the gcc parser).

I believe the plan is for gcc to provide a build server to which the debugger could ask, "expand this expression for me please".