Kernel Debugging: Difference between revisions

Debugging is essentialy being able to probe the contents of a variable at a specific breakpoint.

That being said, there are also alot of other advantages to using a VM.

But thats not all, you can compile your source code under gcc with debuging symbols using "-g". This will add all the debuging symbols in the kernel image itself (Thus making it bigger ). There is also a way to put all of the debugging information in a separate file using the "objcopy" tool, which is part of the GNU binutils package.

I won't start explaining all the nice things about gdb, but as you can see, it is a very powerfull tool for debuging OSes.

Suppose you want to develop your VFS interface implementation. Your already created the interface for block devices (doesn't matter if you already implemented it in your kernel). In this case, you can implement your block device interface as a set of wrappers that [http://en.wikipedia.org/wiki/Adapter_pattern adapts] your interface to POSIX calls. You will then implement your VFS interface (i.e., the code that will manage the filesystem drivers in your kernel) on top of those wrappers. You will then test&debug your implementation all in the hosted environment, and when it is mature, you link it into your real kernel instead of into your hosted implementations. You will finally test your newly introduced code, now in the freestanding environmentm to ensure it works there as well.

There are some Cons on this approach. For example, you are far from your target environment when you code like this. This is further agravated by the fact that so-called ''freestanding'' environments are dramatically more sensible to undefined behaviour, specially unitilialized variables. You can workarround this limitation by asking the compiler to perform aggressive optimization while testing hosted, which make software more sensible to undefined behaviour, too. However, as the best debug environment is the final target environment, you will still want to test your code when you introduce in into your real kernel.

Another Con that will probabilly scare most people is that this approach requires you to consistently plan your interfaces beforehand. Depending on your specific requirements, you may still be able to avoid a too long planning phase. For example, if you want to throw away the hosted implementations once you get the modules working properly, then you don't have to bother maintaining the same interfaces forever.