- 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.
- 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...
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.
I think that's far too cynical. gdb is fine, but there is tons of room for improvement, and more competition in this area can only be a good thing. It is early days yet for LLDB, but it is a promising start.
I've yet to see any IDE/debugger setup on a Unixen that comes close to competiting with Visual Studio's debugging interface, as unfortunate as that is.
You're saying that being able to statically link a library into a commercial app has no business value to anybody because you are fortunate enough to have found a niche where you didn't need to. Your personal experience is enviable, but I don't see how it speaks to the general case.
- 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...