GSoC 2016: LLDB Support for KDevelop - Final Report
The aim of this post is to provide an insight into various aspects of the LLDB plugin, so that it is better understood, and can be used by more people. Should anyone want to improve it or add more features, he/she will also find useful technical details here.
In general, the LLDB plugin teaches KDevelop to talk to the standalone LLDB MI Driver (
lldb-mi), so that it’s possible to use LLDB as an alternative debugger backend for KDevelop.
The rest of the post is orgainzed as follow
- Setting Up provides necessary information on how to get everything work from source code
- Features gives a detailed description of available features implemented in the LLDB plugin
- Roadmap lists some future works.
Custom Build of LLDB
First thing first, you need a working LLDB before you can use it inside KDevelop. For the LLDB MI Driver (
lldb-mi), while it’s a standalone executable, its code is inside the LLDB repository and thus should come with a normal
However, as the current release of LLDB MI Driver contains several bugs, you have to build LLDB from source, with patches applied. Please refer to Building LLDB for more detailed information on how to compile.
To apply patches, after checking out the source code, run
cd llvm/tools/lldb/tools/lldb-mi patch -i /path/to/patch.patch
Right now, only the patch for Bug 28026 is mandatory for stable reason, but there are patches fixing other minor problems available, too, please refer to Current Status of LLDB Plugin for KDevelop for a complete list.
Build KDevelop From Source
While the LLDB plugin has been merged into the master branch in KDevelop repository, it is not included in any release yet, so you need to build KDevelop from source. You can find step-by-step guides on the community wiki. Also, if you don’t want to use
kdesrc-build, be sure to refer to my post for how to avoid messing up with system installed KDevelop.
This section gives a detailed introduction for important features.
As already covered in my previous post, the LLDB plulgin provides the same configuration interface as the good old GDB one. When editing a Debug configuration, the combox at the top-right corner in the Edit Launch Configuration dialog lets you select either GDB or LLDB as backend.
While the defaults should work in most cases, the LLDB backend is configurable in many aspects. Options are grouped into three categories.
- Debugger: settings about where to find the debugger executable and how to launch it.
- Options: settings that control various behaviors during a debugging session.
- Remote Debugging: settings specific to remote debugging.
|Setting name||Default value||What does it do?|
||The LLDB MI Driver executable|
||Empty||Command line arguments passed to the LLDB MI Driver when launching|
||Default Profile||Environment variables for the LLDB MI Driver (not for the inferior)|
||Yes||Whether inherit system environment variables when launching the LLDB MI Driver|
||Empty||This script is sourced by LLDB right before launching the inferior|
||No||Whether stop at the entry point of the program when launching the inferior|
||Which tool view should be raised up when staruing the debugging session. Available options are
||No||Do remote debugging or not|
||Empty||The address of the remote debugging server, in the form
||Empty||A writable directory on the remote machine. Compiled inferior would be put into this directory for executing on the remote machine|
Breakpoints is a must for any debugging tool to be useful. And the LLDB-powered debugging backend also provides good breakpoint support. Apart from setting breakpoints by clicking on the left side of the source file, the breakpoints tool view shows all breakpoints in the project as usual.
Easily getting lost when debugging multi-threaded program? Framestack tool view comes to rescue. Navigating among threads and frames is as easy as clicking the corresponding item. A little difference from GDB is, low level functions like
__libc_start_main are also shown in the list.
The variables tool view shows local variables in the current frame, as well as values of manually set watches. Thanks to the newly written data formatter (equivalent to pretty printers in GDB), the LLDB backend understands common
Qt types, as well as a few
KDE types. This means,
QString are shown as string. Array-like types (various list/vector) and dictionary-like types (various map/set) are also shown in a human readable format.
Unicode values and byte array
Unicode values are safely escaped and unescaped when transfered between KDevelop and the LLDB MI Driver, this means they can be correctly displayed in the UI, rather than showing garbage symbols as the case for pretty printers in GDB.
By hovering mouse on a variable name in the source file, it’s value is revealed in a popup, correctly formatted. Clicking
Watch this adds this variable as a manually set watch. Unfortunately,
Stop on change doesn’t work yet, due to the lack of necessary commands in the LLDB MI Driver.
Using data formatter scripts outside KDevelop
The data formatter scripts bundled are not specific to KDevelop, and can actually be used directly in plain LLDB CLI. Just import the corresponding script
command script import /path/to/formatter/qt.py, and you’ll get the same pretty formatted variables in plain command line.
The scripts usually can be found in
/usr/share/kdevlldb/formatters after the installation of KDevelop, or you can get the latest git version in the repository, they are in
The debugger console is totally reworked. The new ‘repeat’ mode can save you a few types if you want to resend the last command.
Remote debugging has also been redesigned and should be easier to use. The configuration is largely simplified. After specifying the address to the remote debugging server and a writable working directory, KDevelop will take care of uploading and starting the inferior.
However, there are a few limitations in this version. That post also has a comprehensive list of related bug reports in LLDB.
Other than finishing up missing functionalities in the LLDB plugin, the TODO list is as follow:
- Get bugs in lldb-mi fixed
- Global debug config for attach to process and examine core file
For a comprehensive technical TODO list, please refer to
plugins/lldb/TODO.txt in the repository
The executable for the LLDB MI Driver is
lldb-mi, which usually can be found in the same directory as the main
This happens after all internal commands issued by KDevelop, so you have chance to change every settings available in LLDB. But be careful because KDevelop relies on several settings to work properly. ↩︎
While LLDB uses GDB Remote Protocol, it’s only compatible with LLDB’s own implementation, which can be launched by the command line
lldb-server gdbserver. See Known Issues for more information. ↩︎