> > > > While I sort of see Linus' point, there are two cases where it falls down > most often for me.
Actually, I don't see any part of Linus' point. Kdb is a tool, just as much as vi or cscope are tools that aid in kernel development. Anyone who would throw away a useful tool because he doesn't think it is pretty (or that a tool should be used at all) is a fool. The biggest advantage to kdb is its ability to help understand code more quickly than just reading it. The ability to stop at a particular point and see how you got there can aid in the process of learning the source and the multitude of pathways through the code. Additionally, one can often repair a defect by modifying a register and continuing, thus increasing productivity over debug techniques that include printk() and reboot. scott > > Firstly, roughly half the bugs which I track by poking around with GDB are > caused by toolchain/compiler problems, not by bogus code. Looking at the > code and thinking hard does _not_ help you here. You have to see what's > buggered, compare the code with the asm and slowly find out what went wrong. > If BUG() contains a breakpoint and you can poke at it all immediately, > that's a _lot_ easier than forty-five recompilations and reboots with extra > printks in random places, the final one of which changes the compiler's > output so it no longer exhibits the same bug. > > Secondly, the point about not having a debugger making you more careful may > be true - but half the time I track bugs, they're not in my own code. In > fact, I'd go as far as to say the 99% of the bugs I actually use GDB for > aren't in my own code. Some _other_ bugger has been careless, and I'm here > trying to pick up the pieces. > > (Sorry for taking the bait - but anything's better than the evolution thread) > > -- > dwmw2 >
