the issue is not with gdb's UX - you can build as many cool UI / UX on top of it as you want. The problem is that gdb will sometimes take 5 minutes to start debugging (and that's without debuginfod), straight up crash, be unable to resolve obvious symbols etc. which are all back-end bugs. For me developing a medium-sized C++ app, it's really hell to use and usually printf debugging is MUCH faster in the sense that I have the time to find and fix my problem through an iterative recompile cycle sometimes before gdb has even finished parsing my binary
If you run gdb-add-index on the relevant binaries ahead of time it should start up much faster.
Out of the box GDB is kinda awful, especially for C++ codebases. I should probably look into scripting at some point, but meh. Even then, as far as I know I'm the best at using a debugger at work by a wide margin, but I attribute that more to my knowledge of low-level programming than my ability to use most of the basic GDB commands. Also, it tends to crash once a month or so.
If I needed to debug a userland program on a small Linux embedded system, I'd probably whip out gdbserver and attach gdb to the target remotely. I haven't done that in a while though.
- lldb takes 40 seconds to reach "main"
- 2 minutes 36 total to reach the GUI and start being able to reproduce things
- gdb coredumps as soon as I want to put a breakpoint so it's unuseable
$ lldb --version
lldb version 19.1.7
$ gdb --version
GNU gdb (GDB) 16.1