[zwieback]

Everyone here seems to thing GDB is awful. It's been a while for me but I remember using front-ends like Eclipse's CDT or similar and didn't find that experience so bad. Do most people use GDB straight-up? I haven't done that in probably 15 years although it's nice to have a lightweight command line on small embedded systems.

[jcelerier]

> Everyone here seems to thing GDB is awful. It's been a while for me but I remember using front-ends like Eclipse's CDT or similar and didn't find that experience so bad. Do most people use GDB straight-up? I haven't done that in probably 15 years although it's nice to have a lightweight command line on small embedded systems.

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

[khuey]

> The problem is that gdb will sometimes take 5 minutes to start debugging

If you run gdb-add-index on the relevant binaries ahead of time it should start up much faster.

[jcelerier]

Said binary is modified by me every time I change something while building (and I used to build with gdb-index but recently this caused crashes with another build flag so I had to disable it.. though maybe it's fixed with last gdb release?)

[boricj]

I do use GDB straight up for native programs and microcontrollers, mostly out of laziness. I haven't set up VS Code debugging at my current day job yet and it's been 6 months.

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.

[jcelerier]

example from today, timed with a stopwatch, on a 5950X 5GHz CPU: from the moment I click on "debug" in my IDE,

- 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