[gregthelaw]

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.

[modeless]

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.

[dzaima]

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.

[gregthelaw]

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.

[feelamee]

> What features do you most miss?

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

[leni536]

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

[quotemstr]

> excepting weird hacks like evaluating `print c.begin()` and catching it output)

Why do you consider that a weird hack instead of legitimate programming technique?