The LLDB Debugger
llvm.org
The LLDB Debugger
1–10 of 36 posts
Re: The LLDB Debugger
#2Hopefully this replaces GDB, and good riddance.
Re: The LLDB Debugger
#3So basically they want to a debugger as good as gdb, but BSD licensed. I think if this actually matures into something decent, the competition will be good for both projects.
Re: The LLDB Debugger
#4So basically they want to a debugger as good as gdb, but BSD licensed. I think if this actually matures into something decent, the competition will be good for both projects.
Sounds like 'better', being built around a set of libraries first, with the ability to write plugins/extension in a reasonable language like Python.
Most software written originally 20 years ago is going to seem crusty, and have issues in a field as young as computer science -- there are just better ideas and practices these days compared to when GDB was first started, not even considering licensing issues.
Compare the architecture of Airplanes between WWI and WWII to the modern Jet age -- and real software development is still young compared to Airplanes, so yeah, its competition, but as long as it develops into a successful project, I'd expect it to be quite a bit better than GDB in the long run.
Re: The LLDB Debugger
#5So basically they want to a debugger as good as gdb, but BSD licensed. I think if this actually matures into something decent, the competition will be good for both projects.
Sounds like 'better', being built around a set of libraries first, with the ability to write plugins/extension in a reasonable language like Python. Most software written originally 20 years ago is going to seem crusty, and have issues in a field as young as computer science -- there are just better ideas and practices these days compared to when GDB was first started, not even considering licensing issues. Compare t…
Yes -- antirez who wrote Redis wrote linenoise, a replacement of the 20k lines of the old GNU readline in about 400 lines of C for only the 99.99% of users who are on VT100 terminals. http://github.com/antirez/linenoise
Re: The LLDB Debugger
#6Any news on how much progress this is getting? Or a more top-level page, with more than (private-view-only) mailing list links? I'd love a decent competitor to GDB.
Re: The LLDB Debugger
#7Hopefully this replaces GDB, and good riddance.
GDB 7.1 is a great improvement over previous versions and has a lot of the features LLDB intends to have - better C++ support, better thread debugging, more accurate backtraces, and a Python scripting API - as well as some features that aren't on the LLDB roadmap yet, like tracepoints for debugging time-sensitive code and multi-program debugging. You should check it out if you're unhappy with an older version.
Re: The LLDB Debugger
#8So basically they want to a debugger as good as gdb, but BSD licensed. I think if this actually matures into something decent, the competition will be good for both projects.
Sounds like 'better', being built around a set of libraries first, with the ability to write plugins/extension in a reasonable language like Python. Most software written originally 20 years ago is going to seem crusty, and have issues in a field as young as computer science -- there are just better ideas and practices these days compared to when GDB was first started, not even considering licensing issues. Compare t…
Of the tangible features that they list as motivation:
- Build libraries for inclusion in IDEs, command line tools, and other analysis tools - gdb seems to have it http://sourceware.org/gdb/papers/libgdb2/libgdb_toc.html
- High performance and efficient memory use - I cant comment on how much of gdb's sluggishness in running programs is inherent in the problem, and how much is gdb being slow.
- Extensible: Python scriptable and use a plug-in architecture - gdb has it http://sourceware.org/gdb/current/onlinedocs/gdb/Extending-G...
- Excellent multi-threaded debugging support - GDB could be better - I wish it could stop threads individually, instead of all-stop then all-resume even on a single step. But IIRC there is a project to be able to do something like this eventually.
- Great support for C, Objective-C and C++ - Can't comment on objective-c, but the C++ support has gotten significantly better since GCC 4.5/GDB 7.0 with pretty printing of C++ data structures, and has been steadily improving over time handling C++ mangling.
- Retargetable to support multiple platforms - gdb naturally is widely ported - A remote protocol server, debugserver, implements Mac OS X debugging on i386 and x86_64. - gdb has it
I haven't seen anything that really improves on gdb yet. Maybe (hopefully) I'm wrong...
Re: The LLDB Debugger
#9Hopefully this replaces GDB, and good riddance.
Hum, I'd rather wait and see first. What about the truckloads of tools built around gdb (ddd, etc)? And why this should be any better, because it comes from Apple?
Re: The LLDB Debugger
#10Earlier quoted context omitted.
Sounds like 'better', being built around a set of libraries first, with the ability to write plugins/extension in a reasonable language like Python. Most software written originally 20 years ago is going to seem crusty, and have issues in a field as young as computer science -- there are just better ideas and practices these days compared to when GDB was first started, not even considering licensing issues. Compare t…
Of the tangible features that they list as motivation: - Build libraries for inclusion in IDEs, command line tools, and other analysis tools - gdb seems to have it http://sourceware.org/gdb/papers/libgdb2/libgdb_toc.html - High performance and efficient memory use - I cant comment on how much of gdb's sluggishness in running programs is inherent in the problem, and how much is gdb being slow. - Extensible: Python scr…
It comes from Apple and is bsd-licensed. In this community, this passes for "enhancements" over gdb. Yes, this is a bitter comment about the HN community state of mind.