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