The answer, of course, is to do all your debugging in the MIPS kernel, which
even in Linus' tree contains gdb stubs, although I think Linus' tree is
missing the gdbconsole which sends all printk output as GDB $O packets.
(gdb) tar rem /dev/ttyS0
Remote debugging using /dev/ttyS0
0x80110070 in breakinst ()
(gdb) cont
Continuing.
CPU revision is: 00002721
FPU revision is: 00002720
Primary instruction cache 16KiB.
Primary data cache 16KiB.
Secondary cache 256KiB, linesize 32 bytes.
Enabling secondary cache...Done
Tertiary cache present, not (yet) enabled
TLB has 64 entries.
Linux version 2.4.16-0.4 (dwmw2@passion.cambridge.redhat.com) (gcc version
While I sort of see Linus' point, there are two cases where it falls down
most often for me.
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/