I work on game servers that run on both linux and windows. (We deploy to linux but most of our developers work in windows as that is what the client runs on).
If there is a crash or other bug the first question is always "Can we reproduce this on windows servers?".
I spend about 50% of my time using GDB and 50% in Visual Studio for debugging. GDB is just crap compared to Visual Studio has a debugging tool.
I had always wondered what market the window debugging was tuned for.. Building by bug fixing in a debugger and then shipping it to someone without a debugger does seem to be the norm both on windows and in the game industry.
I worked for a UNIX vendor and our gdb style commands were ideal for business and government customers and products.
The time spent diagnosing bugs during production is not nearly as important as the ability to diagnose bugs remotely with limited amounts of data collected (and in many cases read and redacted) by a customer running a machine with sensitive data.
For live debugging we really relied on truss and dtrace. There are ports/copies of them in Linux, I don't know how complete..
Yes, GDB might not be that great for application developers. But GDB is a mighty powerful tool that you can use to debug in various environments.
You can use GDB with a regular user space application or attach it to a dead process with a core file. Or you can plug it to QEMU to debug a bootloader or a kernel image in emulation. Or you can use remote debugging over the network or over the serial port. It's possible to add GDB stubs and run your custom kernel image running on bare metal, debugging via serial connection. You can debug a program running on a microcontroller like Arduino. You can even use it to debug Windows applications remotely from the comfort of your Linux desktop. In my day job and my hacking hobbies I have used all of the ways of using GDB I mentioned in this paragraph.
So yeah, GDB is not a pretty source level debugger like Visual Studio or Eclipse, the versatility comes at a price.
LLVM Project's LLDB debugger may make application debugging less painful in the future.
I just seriously don't understand all the GDB hate. It might have a steep learning curve, but I feel much more comfortable and productive in GDB than I ever did in Visual Studio's debugger.
Is it the most amazing debugger ever? Certainly not. But it gets the job done. LLDB looks promising as an alternative, but it's not mature enough yet.
Also, what's with the fetish with IDEs? I only use an IDE when I write Java (since navigating even a "simple" Java codebase is difficult without one), but for anything else, I spend all my time in vim and a terminal, even for large projects.
GDB is okay once you get the hang of it, but it's seriously less productive than with proper IDE integration.
How do you make a breakpoint? 'break Filename.cpp:1234' or 'break FullClassName::FullFunctionName'. I have to go to my editor, lookup the file and line number, go to gdb and enter a command. Remove a breakpoint? I always forget how to do that so I need to lookup the manual every time. Urgh. I just want to be able to click on a button next to the line to insert or remove a breakpoint.
The command line interface has its uses, but there should also be excellent editor integration. I don't care about IDEs; integration with Sublime Text is fine. Unfortunately every project that I've come across that tries to implement that is half-baked.
Lots of mentions (and warranted criticisms of) GDB for its failings and (especially) nightmarish IDE/GUI integration, no mention of LLDB[0] which aims to fix exactly that (amongst many other things).
OP is https://news.ycombinator.com/item?id=5124476