lldb: how to botch the user interface

Recently I had to spend some time developing on MacOSX. Gentoo-Prefix sadly is getting less and less useful till we don’t make clang a first class citizen (People proposing a GSoC for it are welcome!) so I’m forced to use what’s provided by Xcode. All in all I do like a lot most of the new toolchain: clang instead of an ancient gcc-4.2, a brand new ld replacing a stale binutils. Just lldb is not good.

Clang

clang is wonderful for developing, it is arguably fast at building and the generated code isn’t that bad, beside when you are using asan and it miscompiles… (reported to the asan developers, they will have a look, gcc-asan works as expected.

The warning reporting is probably one of the feature I do miss in other compilers and that’s why I added it to cparser and I’m looking forward to move to gcc-4.9.

All in all clang developers increased the usability of the compiler and made the other projects improve as well, competition in opensource does work.

ld

The linker is again different from the usual binutils, normally you do not notice it but with the new xcode you have to face it since some projects will have problems finding symbols. Again the reporting is quite good, not stellar as clang’s but when the missing symbols are C++ it does a better job than stock binutils in telling you what’s missing from where.

lldb

The new debugger probably isn’t really ready for the prime time. gdb gets its share of complaints about some of its quirks (the macros system is quite minimal and the python interface is good, but not documented as it should), but it is really effective and fast to use.

lldb is not. Almost every command that in gdb is a single statement, and can be shortened to a single letter, in lldb it is two statements , usually with a compulsory option.

Setting breakpoints, watchers, moving through frames; everything gets more cumbersome to use.

The reporting is a little more confusing and the error messages can be misleading. And since you might use the tool while under pressure (e.g. there is a last second bug found before a main release), you want to be as quick as possible.

While debugging some VDA hwaccel improvements for libav I got to spend quite a bit of time tracking why a pointer gets nulled.

The watchpoint I set to figure out triggered at random times in the innards of the osx memory management and I couldn’t actually see when or how that happens.

I ended up writing a dummy hwaccel accessing the same fields on linux, run it through gdb and discover the actual problem in … 10minutes, code and reboots included.

I do hope we’ll see a better interface for lldb and further improvements on gdb (and hopefully combinations such as clang + gdb and gcc + lldb will work better).