As at least the Mac people know, we have had some support for the LLDB debugger simmering in the cauldron for a quite a while. There was some investigative work done a while ago, back then targeted at desktop Mac and based on the library interface LLDB provides. It turned out to be not working too well on Mac, and not compiling anywhere else, and with the existing GDB solution in a somewhat working state, the effort was put on hold.
Fast forward. Time changes environments, changing environments sometimes result in different answers. In times of Qt-on-iOS and with Apple's support for GDB dwindling, it became quite clear that we will need support for LLDB as a backend in Qt Creator sooner rather than later and so the work was re-started in the 2.8 release cycle, this time using LLDB's Python interface.
The decision to go with Python is clearly a trade-off. On the "contra" side there's mainly the performance penalty we pay for the interpreted nature of the approach; on the "pro" side there are distribution considerations (it's often easier to just work with an installed "system" debugger than to ship debugger binaries), and there was some hope that we could directly re-use one of the biggest assets of Qt Creator, the "dumpers" (Qt Creator speak), a.k.a. "pretty printers" (GDB speak), a.k.a. "data visualizers" (LLDB speak).
So what works with upcoming Qt Creator 3.0 and LLDB?
Right now the focus is on the "LLDB 300.2" build that's shipped with the Xcode 5 Command Line Tools on Mac. That's the one intented to be used with Qt-on-iOS, and probably the most common setup for the next couple of months. Other versions are known to work to varying degrees, but they are not currently tested at all.
Setting of simple breakpoints, running, and breaking are working. Stepping, especially around inlined function code behaves sometimes quite differently from how GDB would behave, but since that part of the functionality is completely done inside the backends, there is not really much Qt Creator can (and possibly even should) do. The situation is also not really different compared to the GDB-vs-CDB situation, so I trust people with a genuine cross-platform background to consider this bearable.
Display of basic data and plain C-style structures work just fine. Also, 184 of 226 dumper tests pass, meaning that the bulk of non-trivial display is also there. The remaining FAILs are fairly distributed. There are a few missing implementations and some cases of slight variations in visual output compared to other backends. At least one item looks like broken debug information produced by Clang, and a couple of issues are caused by type lookups in LLDB. Nothing that would count as a show stopper, though.
Also working are quite a few bits and pieces all over the place. Disassembler views (including steppings) and Registers work, as do "Evaluated Expressions", and of course Stack view with frame switching, etc.
What doesn't work?
Roughly speaking, "anything else". Some of the views need some extra nudge to be populated (Modules->Update Module List, ...), some aren't handled yet at all (Snapshots, Source Files, ...).
And for the future?
"Finishing it", clearly. There's still a lot of glue missing, even things that are trivial to fix. There is some headroom on the performance side, and it's currently not yet feeling robust. Not unusable, but not comparable to GDB on Linux, either. Given the past experience with the other backends, this maturing will accompany us during some more minor releases.
The environment is, for a change, quite refreshing to work with. The available interfaces are rather complete, thanks to the use of SWIG. Typically, the question is not the so far customary: "How can I get hold of this piece of data at all?" Often it is: "Which of the functions is best, or fastest, or the recommended one?" (In case some LLDB developer reads this here: Big thanks, and hats off!)
All-in-all, I am pretty confident we are on the right track here, including the option to leave the Mac-only corner soonish. Qt Creator 3.0 will support both GDB and LLDB as debugger backends on Mac. Neither will be perfect, but if you want to help to improve the situation, either by filing issues in the bug tracker or even by contributing real code, go for LLDB.