Qt Creator and LLDB

Published Tuesday November 12th, 2013 | by

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.

Did you like this? Share it:

Posted in C++, Mac OS X, Qt, QtCreator

7 comments to Qt Creator and LLDB

TheBootroo says:

Hi ! I’m using CLang/LLVM on Linux since months, and I wonder when I’ll be able to use LLDB with QtCreator on Linux, since I already have /usr/bin/lldb exectuable installed on my machine…

André Pönitz says:

@TheBootroo: The presence of the executable does not necessarily mean it works. At least a few months ago when I started with the LLDB integration, LLDB was not working well on Linux (i.e. no stepping, no breakpoints hit reliably) even from the command line.

But it’s rapidly moving, and I wouldn’t be surprised if it’s much better in the meantime. Just try it. There’s nothing in Qt Creator code that prevents use of LLDB on Linux. In fact, I would expect /usr/bin/lldb even be automatically detected as valid debugger (Check in Tools->Options->Build and Run, Debugger) and you should be able to select as debugger in your active Kit, or clone the kit and change the debugger there, and press “as usual”.

Danny says:

As a Qt/Mac developer, this can’t come too soon.

When are pretty-printers going to be implemented for C++11 types like shared_ptr, unordered_hash etc?

Also, are there going to be configuration options in the UI? Right now all you call you can do is enable LLDB.

Andre' says:

Have you checked? std::shared_ptr and std::unordered_map (I assume that’s what you mean with std::unordered_hash) has been supported “for ages” for libstdc++. With libc++, std::shared_ptr works, too, and the map at least shows the item count.

But to get this straight: I am more than willing to fully support such cases “for completeness sake”, but priorities are related (among others) to “number of people affected”. We are currently talking about percentage of people using Mac times percentage of people using clang-and-libc++-and-c++11 times percentage of people who use std::unordered_map instead of QHash, so this pretty much boils down to the standard answers.

ShiftZ says:

From my experience, GDB extremely slow on both mac and linux. It takes about 5 seconds to just start the application! Then, if breakpoint is hit, it will take another 3-7 seconds to just show me the piece of code. This is absolute insane. Imagine the efforts to tolerate this since i moved from MSVC, where everything is just instant.
So, my choice fell on Mac with LLDB and QtC.
I have to say, i did not noticed any performance issues mentioned in the blog above. Compared to GDB everything is ten thousands times faster. But, there is a bunch of bugs that prevents me from using lldb. And it’s not the case of ‘hard to use’, it’s the case of ‘impossible to use’.
That one is most annoying: https://bugreports.qt-project.org/browse/QTCREATORBUG-10813

So, i’m still with GDB, unfortunately.

André Pönitz says:

The reason for having public beta releases is to learn of such issues and fix them before the final. So: Thanks for the report.

Commenting closed.