Hacker News Reader

Comment by grogers | Hacker News Reader

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

View on HN

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.

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

GNU readline is a bit of a bloated monster but it gives many programs vi-mode. Like gdb.

I just use "read" which is only one line of code, and has about as many features as linenoise.

readline is "bloated" because it actually does something.

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

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.

Yeah, pesky entrepreneurs and their eye for opportunity.

Well, my company only works on gpl stuff and doesn't suffer any inconvenience from that. So I call bluff.

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.

I actually think that proprietary software is morally wrong anyway. Blasphemy! :)

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 absolutely right. However lldb hasn't gone that far so we can't know for sure if it will ever be any better than gdb.

I'll admit easily that gcc messages/gdb debugging actually suck wind :)

For "high performance GDB", see tracepoints, which act somewhat like DTrace probes.

Reply on news.ycombinator.com