Re: [Linux-ia64] Announce: kdb v1.9 is available for kernel 2.4.16

[slurn@verisign.com]

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