LLDB is a piece of crap (update: maybe it’s clang) (update 2: it’s actually ccache)

I’ve been really trying to use LLDB for a while now. Not that I really want to, but Apple went out of its way to make sure I had little choice. Not only is LLDB the default on MacOSX now, but GDB is really hard to make work on that platform as well. Can you imagine you have to generate a digital signature?

The first thing I don’t like about LLDB is its totally painful command structure. The LLDB authors published a GDB-to-LLDB conversion map, which they probably think is helpful. But to me, all it shows is that LLDB commands are more complex and more verbose than their GDB counterparts, with no obvious way to infer the LLDB command from either GDB experience, or from any kind of logic.

But the thing I dislike the most is that LLDB plain does not work, even when used with Apple tools, in a number of situations that I happen to hit practically on a daily basis. For example, it appears to be consistently unable to set breakpoints by file name and line number with command-line options that are should be used frequently enough to just work.

Here is an example session that illustrates the problem.

ddd@Marypuce tmp> cat glop.cpp
#include <iostream>

int main()
{
std::cerr << "Hello World\n";
}
ddd@Marypuce tmp> c++ -c -g glop.cpp -mmacosx-version-min=10.6 -o glop.o
ddd@Marypuce tmp> c++ -g glop.o -mmacosx-version-min=10.6 -o glop
ddd@Marypuce tmp> lldb glop
Current executable set to 'glop' (x86_64).
(lldb) b glop.cpp:5
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb) ^D
ddd@Marypuce tmp> c++ -g glop.cpp -mmacosx-version-min=10.6 -o glop
ddd@Marypuce tmp> lldb glop
Current executable set to 'glop' (x86_64).
(lldb) b glop.cpp:5
Breakpoint 1: where = glop`main + 22 at glop.cpp:5, address = 0x0000000100000e56

[Update] I initially thought the -mmacosx-version-min=10.6 option was necessary for this problem to show up. But it’s also broken without it. I ran the c++ commands with -v to see what the difference was, and apparently, it’s many little things. So separate compilation with debug symbols just does not work. OK, maybe it’s more a compiler thing than a debug thing. So maybe LLDB is not the piece of crap there. Still, that’s where the problems shows up.

This annoying bug shows how fragile this new support is. By making LLDB the default, and integrating it relatively well within Xcode, Apple is trying to slowly boil a frog here. But if you use the tools in a non-standard way, you might be burnt.

[Update 2] I incorrectly blamed clang and lldb for a problem that is actually with ccache. I am running ccache version 3.1.9 from MacPorts. If I get it out of the way, everything is back to normal. I sent a bug report email to the ccache, clang and lldb mailing lists hoping this will help someone else.

2 thoughts on “LLDB is a piece of crap (update: maybe it’s clang) (update 2: it’s actually ccache)

  1. I don’t know for LLDB but GDB is the worst debugger I ever used in my life. And I used a lot of debuggers, on a lot of systems (mac 68K, macPPC, OSX, embeded, windos, etc.) It’s a good friend for gcc who is another great piece of trash. Both are amazingly sloooow, buggy and unreliable. Apparently there is no QC in those projects…

    Frankly I prefer to work with ThinkC debugger than debugging (with) GDB… I miss CodeWarrior so much when I have to work on Mac system…
    To avoid working with gnu junk as mutch I can.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s