Slightly off topic but I think it is a good place to ask:
One of the few things from windows that I miss when using linux is the debugging experience with visual studio (not code). When debugging a medium-sized C++ project on windows, the launch of the debug build is pretty fast and stepping over lines is almost instantaneous. On linux launching the executable using gdb takes like 10 seconds loading modules and stepping over each line takes like half a second which I think is intolerable (lldb is even worse). Yet I don't see people complaining about this online very much. Am I missing something? E.g. is there a compiler flag that speeds up debug launch time and step speed that I am not using?
Yea, our software stack pulls many dependencies (our software probably totals over 200k loc). We depend on Qt, OpenCASCADE, and a few other heavy C++ Libraries. Stepping over a single line of code in GDB using the TUI can take 3-5 seconds in the worst case. I’ve been meaning to investigate or profile it further when I get the time, but it functionally means I avoid using the debugger except as a “last resort”, or only using it to catch segfaults or unhandled exceptions.
It’s very odd. It’s like it doesn’t cache something and ends up doing some strange expensive symbol search every time it hits a breakpoint or something.
Curious if anyone has a good solution to this also
A long time ago, "set use-deprecated-index-sections on" improved some things; don't know if any modern compilers need that anymore. I also have a "disable pretty-printer global builtin" in my ~/.gdbinit, though I don't recall what that was for, or if I even determined that to improve speed. Currently it seems "set style sources off" reduces some startup time. Don't think I've debugged anything your scale though, and I doubt any of my suggestions will actually help.
Ensure you're building with DWARF5, and enable accelerator tables like .debug_names, which will allow debuggers to receive a pre-prepared index of the symbol names in the program (and thus it doesn't have to parse all the DWARF on startup).
Slow stepping is a surprise; there's no OS reason for that to be slower. Possibly if your types are really large and complicated, the debugger has to fetch a lot of data to refresh its view of state each time?
> I don't see people complaining about this online very much
I complain about gdb all the time, speed is just one aspect. Step-by-step debugging is just terrible on Linux. Maybe that's actually the reason few people complain about it, they just don't use gdb, instead relying on other tools, especially printf(). I am not in the video game industry, but they seem to be way, way ahead of everyone else, especially Linux (non-game) developers. Maybe some collaboration is in order.
As for your specific problem, I don't know. Do you have optimization turned on when debugging? gcc/gdb and the LLVM equivalents let you debug optimized builds, but it is not ideal as knowing which instruction corresponds to which line is complicated, and maybe gdb is working extra hard for it. The "-Og" flag is supposed to only do "debugger friendly" optimizations, also "-ggdb" or "-ggdb3" is supposed to be better than plain "-g" for use with gdb.
Haven't observed anything like that. Even with remote gdbserver on a low power embeddeded device, stepping has always been instant for me. Could be a C++ vs C thing.
The only thing which takes time is debuginfod downloads.
This is opposite the typical experience so you have some wedrd setup. Gdb is instant and VS' debugger takes forever. It's why companies like epic games have their own debuggers
