This is my personal blog about programming. In my 20+ odd years I found that programming is mainly problem solving. In my earlier days I was handed out the Pure Mathematics book by Hardy and found that what gem it is. Clarity, chronology, and preciseness has been achieved at the highest level in my opinion. So that inspires me a lot... And I try to follow it in my professional career. And that is the only reason I gave this blogs objective - Pure programming!

Once you setup your remote debugging environment, it is your hard work ( always) to figure out how you debug, when you debug. Assuming that you that you are somewhat familiar with kernel debugging, which includes debugging core operating systems, boot code, code related to device or other system resource frameworks, you would be looking at some basic commands that would work reliably, for example -

*) Breaking into debugger, mapping symbols, looking at sources etc.

*) Run the kernel under your debugger, and probe, steps thru the code etc.

OSX started out with GDB debugger, and moved to LLDB. LLDB maps some of the GDB commands (if not all, but I don't know yet), but it is quite verbose to type most of the commands. I read it as Long Long Debugger.

GDB as such is quite old and popular, but when it comes to kernel debugging there are many local shop to shop customized gdb. But one general one is kgdb. It is not a true sense kernel debugger, though.

So what is a true kernel debugger?

A true kernel debugger is one which freez the time when you broke into debugger. So if you leave your debug envrionment overnight, you must see old time, date. Lot of kernel debugger in the open source are really not there. Hence, it is quite difficult to debug some of the hard problems like once in a blue-moon race etc.

Windows kernel debugger outshine in this case. Before it windows softIce was another one. But in GNU open source environment, I'm yet to see a "True kernel debugger".