Wednesday, July 10, 2013

State of LLDB on Linux

I've had this question pop up a few times now. Can be summed up as "why is Rad/Valve working on LLDB on Linux - isn't it already done?" Some people get a bit aggressive about it:
Roberts then followed up with another Tweet, "To be more clear: RAD is looking for developers to write debuggers. We are working on lldb on Linux currently..."
Seriously? The giant's share of the work is coming from Apple. RAD is either exaggerating their intent, talking out their ass, and or both. What little they are working on is testing and bug tracking to make sure LLDB is not broken on Linux. LLDB has been working on Linux for nearly a year.
Sometimes I wish I could Gong Show portions of the Internets.

Many good folks have done a lot of wonderful work and made a lot of progress the past year on Linux LLDB. This includes four developers we've recently met at Intel, as well as several from Apple, FreeBSD, and others - but there is still a _lot_ to do before we can use LLDB to debug L4D2 and TF2. Or even LLDB. Or even a 32-bit version of printf("talking out our asses!");

When we started working on this a couple months ago, you couldn't list currently running Linux processes or attach by process name. Major features like threading and split symbol support have just recently been added. One month ago you could not debug multi-threaded applications or step into system libraries with symbols or source.

As of right now, you still can't load core files and debugging 32-bit Linux applications pretty much just doesn't work. We just started looking at the i386 test suite today.

DWARF4 symbols (the default for gcc 4.8) do not work.

Expressions can be shaky and backtraces could use some sweet, sweet lovin'.

I'm tracking down an assert and crash loading the nss shared library right now. (See last blog post).

Several tests in the test suite currently fail on 64-bit Linux.

33 of 262 tests fail on 32-bit Linux.

Linux LLDB has a tendency to hang at times, and I'm currently seeing some crazy long target load times.

There is no remote debugging on Linux.

For more, take a look at the current Linux lldb bug database:

There was a good blog post about LLDB 3.3 recently on that is well worth reading.

There is a lot to like about LLDB, and we have really enjoyed the community and working on it. There is also much to do before we can ditch gdb and use it fulltime. If any of this work sounds interesting, please jump in and help!


  1. Agree with most of the points, there are lots to be done before lldb actually can takeover in Linux but that day is not too far.

    If anyone interested in elf core file support - I have a working patch for core files(Linux elf x86-64bit) and it should be committed soon.

  2. Definitely interested in core file support. We use them a decent bit with our game remote servers. Thanks Samuel!

  3. What is the problem with using gdb?

  4. I actually like (most of) gdb and use it all the time. However LLDB has a well designed multithreaded C++ interface, and I think that makes more sense to build a GUI on top of.