We’ve spoken in the past about teaching Clang to fully support Windows and be compatible with MSVC. Until now, a big missing piece in this story has been debugging the clang-generated executables. Over the past 6 months, we’ve started working on making LLDB work well on Windows and support debugging both regular Windows programs and those produced by Clang.
This, and Roslyn…busy times in compiler land
Is it better than GDB ?
Not really, it’s pretty much same. In the past people touted it as a faster debugger, but i never felt the difference.
But it integrates better with IDEs using a public API (LLDB SB API), that is arguably far better than scrapping the output and injecting commands of GDB-MI mode (albeit LLDB also have a GDB-like MI mode).
I find the debugger a bit faster with breakpoints and watches, but probably not so much as it matters. I do like the clang compiler more though. I personally find it to be faster, gives better error messages, etc.
But the big thing for me, is that the codebase is much cleaner and easier to work with (both from what I have seen, and from colleagues who have touched it). GCC is a mess, and they know it.
So having an alternative on as many platforms as possible is a good thing. I am personally investigating switching over to clang/LLVM for my embedded work.
It’s not better than gdb, at least not yet. In my experience of using both, lldb is lacking certain features I rely on. For example “catch throw” and “catch catch”; they are currently broken, but you can work around it (somewhat) by breaking on __cxa_throw (in current Apple XCode tools). And the amount of detail in backtraces and the amount of introspection you can do was quite limited last time I tried it previously, though when I used it again recently it had improved. I’m sure it will catch up given time. My main annoyance is that it’s not using the same syntax as gdb, which makes using it hard when you have over a decade of gdb muscle memory to replace.