[bieganski]

> The available Linux debuggers are gdb and lldb. They both suck. They crash all the time, don't understand the data types I care about, and they don't make the data I need available at my fingertips as quickly as possible.

Okay, so this is the author's answer to the most important question: "why?"

For me this is a serious issue, making strong statements without any single backing example. If you experience crashes, please report to the maintainers - i guarantee that you won't be ignored. You say that it's missing some data that you need? Fine, but be precise - what data?

Otherwise it sounds like a "yeah, let's make a project for fun and pretend that it's serious by finding sort-of-justification/use case" (i'm not telling that it is the case for you - i'm telling that it sounds like it, based on your own description).

Also, would you feel nice if i put in my project's README a note that the project of you, the one that you put your effort to, "sucks"?

[dumah]

There are almost 4000 open issues on gdb reported more than five years ago.

In this conversation are reports of an annoying bug that requires a user patch gdb and it's existed for almost twenty years.

It was years before anyone was even assigned because of a bug in their bug tracking system, and they haven't addressed any further comments over the decades.

[omnicognate]

I'd rather the time taken enumerating the deficiencies of existing debuggers be spent building something better instead. I doubt many people that have used gdb/lldb need convincing that that's possible. If it is needed, Microsoft's windbg (far from what's possible but light years ahead of gdb/lldb) is a proof by construction.

[ethin]

Bit of a possibly unpopular take but I very much disagree. The syntax of windbg/cdb is just... Really bad. I feel like I'm writing assembly and the mnemonics don't actually align with what the command does. So it's difficult for me to get confident with it. At least the commands in gdb make sense (and I wish gdb supported windows executables, but alas...)

[matu3ba]

windbg has no sane library api, which makes it by construction unsuitable for automation and inspection.

I'd personally prefer, if we would have the options of multiple time-travel debugging sessions based on synchronization points (if needed) being overlapped to single out bugs in interesting areas (not covered by static or dynamic analysis). Debugger would be essentially a virtual program slicer being able to hide unnecessary program parts or reduce it. However, so far we neither have the options for piece-wise time-accurate multi-threading recording, nor slicing overlays nor in-memory reducers (ideally also reducing AST). I may be mistaken on "piece-wise time-accurate multi-threading", since I've not checked what is possible with hardware yet.

Heck, we dont even have overview data for common bug classes and cost for verification or runtime-checking in academia etc.