It's not clear to me why we'd need a new debugger instead of GDB enhancements. GDB has an extensible, modern C++ codebase with literal decades of hard earned knowledge baked into it.
How are we better off rewriting it, especially if the rewrite isn't memory safe?
> GDB has an extensible, modern C++ codebase with literal decades of hard earned knowledge baked into it.
I literally laughed outloud at this. Have you ever actually opened a GDB source file? It is, as a whole, extremely poor quality code. Almost all of it is doing C string manipulation and raw pointer arithmetic; almost none of it uses C++ smart pointers, nevermind the rest of "modern C++"; the vast majority is completely uncommented, and "literal decades of hard earned knowledge" can be better translated as "literal decades of historical baggage, cruft, and hacks". I regularly cause GDB to segfault in normal, mundane operations.
> It's not clear to me why we'd need a new debugger
People build things for fun. Stop asking "why" and ask "why not?"
No one can really predict what's needed and where we need to go, so let people just explore. Sometimes they won't find things, but sometimes they do. And if they don't, they still gain useful knowledge that pays dividends later on anyways.
I'm considering the part that says "GDB and LLDB pain me greatly". This project both says "I'm doing this for fun" and "the state of the art is bad, and I'm trying to fix it", so this is a fair question.
GDB is great. He says it crashes a lot, and cannot interpret some of his types. Maybe that's his experience, but I haven't had those issues after literally decades of using gdb. Some bug reports would be nice.
After literally decades of occasionally dipping into GDB only to quickly remember why I would rather use no debugger at all than that, it's hard to imagine what you could mean by "great". What are you comparing it to?
Decades for me as well, and we’ve had very different experiences : gdb is very powerful , but the user experience is atrocious and it does crash a lot.
To be fair, in a number of cases the type issues I had were not gdb’s fault but bad DWARF produced by the compiler.
GDB is awful and a replacement is sorely needed. It's buggy and slow and feature poor and has a terrible UI and a terrible API which makes all the frontends terrible in turn. I haven't looked at its code but I'm betting it's terrible too.
I haven't tried UScope yet (I shall), but I don't agree with you about GDB. I don't find it especially buggy unless doing niche things like non-stop debugging -- I guess you may well have a different experience though.
I think the UI is much maligned unfairly. It has a few quirks, but ever used git? For the most part it's fairly consistent and well thought through.
By terrible API you mean the Python? I admit it can be a bit verbose, but gives me what I find I need.
What features do you most miss? My experience is that most people use like 1% of the features, so not sure adding more will make a big difference to most people.
It's been a while since I bothered to try to use it because my experience has been so bad. So I don't remember all my specific complaints about bugs and features. I do remember multi process debugging was a big hole last time I looked. In contrast, I was able to get multi process debugging working really well in Visual Studio.
By terrible API I mean GDB/MI that frontends use. I'm sure people will come try to defend it but the proof is in the pudding and I don't think it's a coincidence that every GDB frontend sucks.
I'll +1 GDB/MI being utter garbage. Bespoke format (ordered multimap as the only keyed data structure, why), weird quoting requirements (or sometimes requirement of lack thereof) on input, extremely incomplete, and in some cases nearly unusable even for what it does support. Feels more like carelessly shoehorning some of the existing gdb commands with a different syntax (but sometimes not different) than an actual API.
If it's been a long time I recommend taking another look. TBF you can tell it hasn't had the millions of dollars of investment that the Microsoft debuggers have, but still it's come a long way over the last 5-10 years.
e.g. it now has decent multi-process support.
I agree MI is kinda horrid, but no need for it these days, you can do everything via the Python API, and the modern equivalent is Debug Adapter Protocol which GDB claims to support now (although I haven't tried).
There a million frontends, including both Visual Studio (via ssh) and VSCode, if you like those.
The perfect developer tool does not exist, but I believe that if you're debugging native code on Linux more than a few times per year then you should really know how to drive GDB. It won't always be the best tool for the job, but it often will be.
one time I wanted to write generic printers. E.g. printer of any type which support C++ iterators. But gdb can't call C++ functions from python api (excepting weird hacks like evaluating `print c.begin()` and catching it output). Although this is not very useful because most of types we use changes very rarely, that's why writing printers is only matter of time.
Another feature is breakpoints which sleep next N seconds. We have breakpoints which can skip next N triggering, but similar with time will be useful to me to debug mouse events in gui apps, etc.
Also the most new gdb still have problems with tab-tab completion (and even Ctrl-C don't return control immediately).
Also lately I often meet problem cannot insert breakpoint 0. Probably this is a bug, because answers from stackoverflow isn't relevant for me
> one time I wanted to write generic printers. E.g. printer of any type which support C++ iterators.
How would that work for types where the required functions are not instantiated, or not instantiated as a standalone function? Most iterators' operator++ are inlined and probably never instantiated as a distinct function.
Thanks, I hadn't seen that, seems like it was just released a year ago. Seems like a step forward. I was talking about GDB/MI, which was the main (only?) option for decades and could still be considered the "native" frontend API of GDB.
Well, you can start by tearing down all the fences and firing that Chesterton guy's sorry ass. After all, even a 32-bit ARMv7 uses .eh_unwind sections to crawl the stack for a backtrace, right?
Then, you can focus on resolving edge cases that can cause papercuts. Make sure the solutions are at the expense of the happy path because that's all been solved long ago so there's no need to pay attention to it.
How are we better off rewriting it, especially if the rewrite isn't memory safe?