On Fri, 2006-01-20 at 16:21 +0530, satheesh paul wrote: > Bernd, > Even if I don't touch the bootloader, what kind of debugging tools will I > need to debug the kernel? Or a device driver? Just printk() :) ? For things printk() is state of the art. You could try to use kdb. > like single stepping or examining registers or memory? Single stepping has the problem that it inherently assumes that speed/time is not an issue and that you are on a (more or less) sequential way through the to-be-debugged program. Both of this hold in typical applications (e.g. a mail reader) but in a kernel you have - hardware interrupts which must be handled even if in single step mode (e.g. the timer). Forget single stepping in a timer routine (except you want to reboot afterwards). - You have the possibility that the actually debugged code path is used by several instances of the same "task" (think of an opened char device after a fork(2) [or dup2(2)] - your driver doesn't actually know (and must not care) how many file desriptors are created after one(!) open(2) call (which your driver will probably handle). and there are probably other similar issues. > And explain me a little more about JTAG. I tried google, but info on JTAG is > so disoriented on the web that I could'nt come to a conclusion. What exactly > does JTAG consist of? Is it a hardware probe which, on the host is connected JTAG as such is a standardized plug + the interface on the board to disrupt the CPU for debugging. You can also upload firmware and peek into RAM. > to parallel port and to the JTAG interface on the board? What software do I Yes. And it must be supported by the board and CPU AFAIK (so you have it on prototype/development boards but not necessarily on the production board). > need to debug with it? Does gdb work with it? IS IT CHEAP?? You need for the access a BDI or similar product which also knows you OS, MM, etc. on that board, so - at last for BDIs - you have different software on the BDI for different CPUs and OSs (and possibly boards too). > Again how do you do your kernel debugging without JTAG or BDI? printk(), boilerplate checks (i.e. BUG_ON()), studying source code (mine and others). Another problem in kernel development is a/the usual aplication ways of coding: - "test it until it runs": You have lots of code paths (esp. for error cases) which are not trivial to trigger for testing (how behaves this file system if double faults are failing under low mem conditions). And how can you estimate (let alone measure) the code coverage of such tests. - "write the code, single step it until it works, done". How do you do this seriously with asynchronous events (even in user-space apps)? And the Kernel is a actually single huge async application - IRQs from the hardware, sys-calls from user-space, timer, ... So you absolutely need a quite good idea of your design and conditions which is enforced with BUG_ON() to immediately identify b0rken behaviour (and not stumble over errors in completely unrelated drivers just because a - probably your - driver writes at the wrong address because you fucked up some index calculation). Bernd -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
