

The LLDB Debugger - wmat
http://llvm.org/viewvc/llvm-project/lldb/trunk/www/index.html?revision=105619

======
robot
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.

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

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

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

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

~~~
pquerna
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.

~~~
grogers
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...](http://sourceware.org/gdb/current/onlinedocs/gdb/Extending-
GDB.html#Extending-GDB)

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

~~~
wazoox
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.

~~~
neilc
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.

~~~
wazoox
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 :)

------
yan
Hopefully this replaces GDB, and good riddance.

~~~
wazoox
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?

~~~
lallysingh
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.

~~~
resistor
> 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.

~~~
lallysingh
Oh wow.

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

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

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

------
ahn
I can't wait until they announce the LLMUA.

