Hacker News Reader

Comment by modeless | Hacker News Reader

It can't be a coincidence that literally every Linux C++ debugger majorly sucks. I think the blame has to lie ultimately with GDB itself and GDB/MI, because it's the only thing they all have in common (except for lldb I guess).

View on HN

I think that the major problem is that gdb was never designed/suitable for graphical debugging. I use Visual Studio on C projects at work, and found it very interesting to find that Windbg actually has similar terrible usability as gdb. Gdb and Windbg were both command line interfaces originally, whereas Visual Studio has it's own debugger backend which was visual-first (afaik).

Really, VS is exceptional even in Windows land. I've tried RemedyDB, an attempted rewrite of debugging on windows, and found it useless. It had similar bugs to this article - no symbols, failure to attach, failed to bind breakpoints at all, failed to display variables.

I think it would be a huge project to replace GDB with a graphical-oriented debugger, but it would be worthwhile. If I were in charge, I'd make it a C lib that didn't come with a frontend. That way, the user can stay in their familiar editor and link the lib. (most programs should be able to use C libraries).

Totally agree that a debugger is the kind of software that majorly benefits from a GUI.

https://headcrab.rs/ is a project to create a modular debugger framework (implemented in Rust, but I think for debugging any native code) which could eventually form a good basis for such a tool.

Only if you use classical WinDgb instead of the new one.

https://docs.microsoft.com/en-us/windows-hardware/drivers/de...

Mac OS also is another example of having good graphical debuggers, even in the MPW days.

I disagree. I was using WinDbg downloaded from the Microsoft Store (so it had the WPF or whatever UI), and it was unusable. (Note: I was using it on a very large project - 4mLOC with hundreds of first- and third-party libs; It's likely I could get some use out of it on a trivial program, but it just didn't get the "real" program; and no, I wasn't simply missing the PDBs).

IMHO the original WinDbg UI was perfectly fine with the exception of a few small oddities; the new one is pointless trendchasing.

Well it is still preview, but definitely much better than the classical one, from my point of view, which looks like created by kernel developers first attempt at a GUI app.

it was in fact created using state-of-the-art windows gui frameworks. in 1995. and then never updated. is it really an improvement to have a win10 settings app that is all unified... except for most of the advanced settings and half of the basic settings which are only available in the control panel?

Win 16 nor Win32 were never state of the art Windows GUI frameworks, just the basic building blocks.

That place is reserved for OWL, VCL and MFC, which WinDbg doesn't use.

my mistake. I thought MDI was new in Windows 95, but in fact it dates back to Windows 3.0, and was in fact deprecated by 95.

I think WinDbg has much better commands than GDB, although that might be because I started with DOS DEBUG (of which WinDbg's commands have a strong resemblance to). Nonetheless there are some things in GDB whose design is definitely perplexing, like the "disassemble" command (https://stackoverflow.com/questions/39016138/how-to-force-gd... )

The only usable gdb-based debugger I have ever seen was Insight

But then it was killed because it was linking to gdb internals rather than using gdb's official api or something

> But then it was killed because it was linking to gdb internals rather than using gdb's official api or something

Oh? Their git repo[1] seems active.

[1]: https://sourceware.org/git/?p=insight.git

The last release seems to be from 2009: http://www.sourceware.org/insight/

Reply on news.ycombinator.com