4 ms·

Is this entire set of comments suffering from people conflating the debugger with an interface to the debugger? In much the same way that sometimes people confl

Is this entire set of comments suffering from people conflating the debugger with an interface to the debugger? In much the same way that sometimes people conflate their compiler with their IDE. GDB is a fine debugger. I've never had any trouble with it at all, and I don't recall ever needing a feature in it that it didn't support but other debuggers did, although I'm not a very demanding user of the debugger; I rarely need more than some conditional breakpoints and the ability to see the value of any given variable or memory location.

qznc 10y ago
If WinDbg were so much better than gdb, someone at Google would have replicated it for Linux. I'm fine with gdb and conditional breakpoints is usually the most advanced feature I need. Only once I used bigger guns. Detecting the error meant run into conditional breakpoint A, then enable and run into conditional breakpoint B (which would have triggered a lot before A), and then inspect a variable. The problem: The error only occured sometimes. Thus automate this via Python, so gdb could auto-reexecute everything until it found the failure case again. What I still miss is multi-process debugging. Gdb can only attach to a single process, so you need multiple gdbs to watch multiple processes and this introduces race conditions.
- EliRivers 10y ago
  You've just reminded me; sometimes I need to run something under Valgrind, and upon Valgrind not liking something, sparking a break using GDB. I expect that's possible using other debuggers, but it's so, SO easy using Valgrind and GDB. So by this reckoning, GDB is the best debugger I've ever used. Bring it, WinDbg :)
AlexCoventry 10y ago
> people conflating the debugger with an interface to the > debugger? It's very annoying. If there are any further cool gdb tricks in the thread, they're hard to pick out from the noise.

qznc 10y ago

If WinDbg were so much better than gdb, someone at Google would have replicated it for Linux. I'm fine with gdb and conditional breakpoints is usually the most advanced feature I need. Only once I used bigger guns. Detecting the error meant run into conditional breakpoint A, then enable and run into conditional breakpoint B (which would have triggered a lot before A), and then inspect a variable. The problem: The error only occured sometimes. Thus automate this via Python, so gdb could auto-reexecute everything until it found the failure case again. What I still miss is multi-process debugging. Gdb can only attach to a single process, so you need multiple gdbs to watch multiple processes and this introduces race conditions.

EliRivers 10y ago
You've just reminded me; sometimes I need to run something under Valgrind, and upon Valgrind not liking something, sparking a break using GDB. I expect that's possible using other debuggers, but it's so, SO easy using Valgrind and GDB. So by this reckoning, GDB is the best debugger I've ever used. Bring it, WinDbg :)

AlexCoventry 10y ago

> people conflating the debugger with an interface to the > debugger? It's very annoying. If there are any further cool gdb tricks in the thread, they're hard to pick out from the noise.