[edsrzf]

> Someone needs to nuke this site from orbit and build a new debugger from scratch, and provide an library-style API that IDEs can use to inspect executables in rich and subtle ways.

LLDB[1] can do this, but I'm not sure how far along it is.

[1] http://lldb.llvm.org/

[to3m]

Judging by the version that's in Xcode, lldb is not ready yet.

The command syntax is a bit inconvenient compared to gdb. Perhaps I should overlook that, because it's presumably designed to be the lowest level of the debugger, so you interact with a GUI or something rather than with lldb directly, but Xcode's expression window is such utter unreliable junk that I end up having to use lldb by hand all the time anyway.

I've had problems with variable substitution. You can (say) ask it the value of $rip to find out what the value of the RIP register is, but if you try to set a breakpoint at $rip, it doesn't know what $rip is.

I've had problems with lldb telling me that a struct is forward-declared, even though I'm trying to print a local value of that struct type.

Sometimes lldb just gets confused, as in this exchange, which I reproduce verbatim, just as it happened:

    (lldb) p this
    (const CustomTrafficStyle *) $2 = 0x200cf4e0
    (lldb) p *this
    error: invalid use of 'this' outside of a nonstatic member function
    error: 1 errors parsing expression

lldb doesn't have gdb's @ operator for printing arrays; instead, there's this separate command for dumping memory. So instead of "p x[0]@100", you might do "me r -ff -c100 `x`" - which is obviously a big pain, because it's a lot more verbose. I don't even know offhand how you'd use an expression for the count argument either (more inconvenient syntax.) (Furthermore, I don't even believe the me command does exactly the same thing, because I don't think it prints structs, but it usually does the job just about well enough.)

Finally, and most tiresomely, lldb will sometimes just print nonsense. So you might end up with something like this, which is all reasonable enough: (made-up example representative output, not a copy and paste)

    (lldb) p x
    (int *) $2 = 0x1234578
    (lldb) p i
    (int) $3 = 100
    (lldb) p x[100]
    (int) $4 = 123
    (lldb) p &x[100]
    (int *) $5 = 0x12345998

But then...

    (lldb) p x[i]
    (int) $6 = 0
    (lldb) p &x[i]
    (int *) $7 = 0xc4231777 

Maddening. Absolutely maddening.

[kevingadd]

As you hint at, Xcode is a part of the problem here. The debugging parts of Xcode (ignoring the horrible things wrong with Xcode as a whole) have always been a pile of junk, even before they introduced lldb. This is complicated by the fact that in my experience Xcode was always built upon a quirky Apple fork of outdated third-party tools.

So, I guess what I'm saying is: Even if lldb isn't ready yet (it probably isn't), you shouldn't judge it based on your experience with Xcode. Being integrated with Xcode would make any piece of software look like junk even if Knuth wrote it.

[millstone]

I use LLDB with some regularity. The last I checked, lldb is essentially at feature parity with gdb in user space (not sure about kernel debugging), and has additional features beyond that aimed at fixing some of the mistakes of gdb.

As a small example of something LLDB got right, say I want to put a breakpoint in this C++ template function:

    template<int X>
    factorial() { return X * factorial<X-1>; }

Because it is a template, this one line in code maps to multiple program locations (factorial<1>, factorial<2>...) gdb will create a separate breakpoint for each location, and each must be managed separately. But lldb maintains a logical / physical breakpoint separation: one logical breakpoint maps to multiple breakpoint locations, so you can manage all of them as a single value, and more easily treat factorial as if were a single function.

(Maybe more recent gdbs do this too - my version is rather old.)

One downside of lldb is that, while its command line syntax is very regular, it's also quite verbose. gdb's 'attach myproc' becomes `process attach --name myproc`. gdb's `up` becomes `frame select --relative=1`.

lldb does have a set of macros and abbreviations that cut down on some of the verbosity, but they haven't always worked well for me, and I hope they overhaul the syntax.

[DannyBee]

GDB still does not support a logical breakpointing syntax, sadly.