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.
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.
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.