Linked by Thom Holwerda on Tue 20th Jan 2015 21:28 UTC
General Development

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.

Order by: Score:
by avgalen on Wed 21st Jan 2015 14:28 UTC
Member since:

This, and Roslyn...busy times in compiler land

Reply Score: 2

RE: Busy
by Kochise on Wed 21st Jan 2015 15:45 UTC in reply to "Busy"
Kochise Member since:

Is it better than GDB ?

Reply Score: 2

RE[2]: Busy
by CapEnt on Wed 21st Jan 2015 16:26 UTC in reply to "RE: Busy"
CapEnt Member since:

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).

Reply Score: 4

RE[2]: Busy
by jockm on Wed 21st Jan 2015 17:08 UTC in reply to "RE: Busy"
jockm Member since:

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.

Reply Score: 4

RE[2]: Busy
by rleigh on Wed 21st Jan 2015 23:35 UTC in reply to "RE: Busy"
rleigh Member since:

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.

Reply Score: 3