How are we better off rewriting it, especially if the rewrite isn't memory safe?
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
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.
It's Hacker News, let people hack.
>I've been building a debugger on my nights and weeks because it's fun
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.
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.
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.
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
Why do you consider that a weird hack instead of legitimate programming technique?
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.
Obviously, it will not. But why not to try?)
> Most iterators' operator++ are inlined
Sure, it's sad.
But I'm still think that such feature - calling C++ functions from Python API - can be useful.
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.
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.
I don't know the details. But nowadays gdb supports DAP, as any other debugger: https://www.sourceware.org/gdb/current/onlinedocs/gdb.html/D...
Are you talking about this, or the old https://www.sourceware.org/gdb/current/onlinedocs/gdb.html/G... ?
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.