Bernd,
Thanks a lot. I have another question.
What is the case with bootloaders? (board bringup is the term used for
getting the bootloader working. right?) Can they be done without JTAG?
With Regards,
Satheesh.
From: Bernd Petrovitsch <bernd@xxxxxxxxx>
To: satheesh paul <satheesh_kernel@xxxxxxxxxxx>
CC: idoit.ief@xxxxxxxxx, fawadlateef@xxxxxxxxx, rabhagat@xxxxxxxxxx,
kernelnewbies@xxxxxxxxxxxx
Subject: Re: kernel development environment
Date: Fri, 20 Jan 2006 12:26:24 +0100
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
_________________________________________________________________
Spice up your IM conversations. New, colorful and animated emoticons. Get
chatting! http://server1.msn.co.in/SP05/emoticons/
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
