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!

Debugging not exactly an interesting thing for most programmer! And this is one of the reason for not many people are ready to debug kernel code written by others. But it is an excellent trade to have!

There a few different ways one can debug kernel code -

-- Passive debugging using message printing.

-- Active debugging under a debugger.

In this part, we will talk about active debugging under kernel debugger. For quite sometime, GDB used to be the debugger of choice with some modifications. GDB by design is not a kernel debugger in true sense. So there has to be some kind of patching that takes GDB to become a kernel debugger. In Linux and FreeBsd world, this is often called kgdb. In OSX, it is just GDB. Recent moves by Apple computer made GDB being not the default debugger. Unless you get a back level source and compile it under OSX, with perhaps some tweeks, it is difficult to get a recent GDB to work as a kernel debugger under current ( i.e 2014 - 2015 ) versions of OSX.

So here comes the LLDB. It is under the LLVM umbrella. It can be used for live kernel debugging, as well as two machine kernel debugging. Live debugging means single machine kernel debugging in this context. And two machines debugging is true sense kernel debugging. Though these machines could be VMs !

Here the setup for kernel debugging is - A laptop or Mini OSX running natively on Intel hardware, and a VM running on Fusion Virtual machine workstation infrastructure from VMware. In a two machine setup, the debugger machine is called the Host or Debugger, and the machine being debugged is the Target. Here the native OSX is the Host, and VM OSX is the Target.

Configuration for VM based debugging, the current discussion here, is different from two machine debugging with both machines running OSX natively. You can always look at Apple developers' site as well as looking at the ReadMe file of respective Kernel Debug Kit for the OSX version you are running. For setting up a VM under Fusion, please follow the instructions from Fusion package, as well as online blogs.

Assuming you have a VM running, one of the thing you need to do is to set the Networking as Bridged Network from one of the menu of Fusion. This will make the setting up and communication quite easy. Once it is set, please take a look at the ifconfig to make sure, the interface that has similar ip is indeed "en0", otherwise you need add another parameter. The detail you can find from any of the ReadMe file of Kernel Debug kits from Apple. Usually it is always "en0" unless you have multiple interfaces.

Now ping the VM from the host to make sure that they can talk over the Bridged network.

Finally before you go and change anything further, make sure you take a snapshot of the VM, so that you can always come back to this point of configuration :-)

On the host, you will need to make a static ip entry using the following format ( with respective ip and mac address from your interface )

sudo arp -s 10.2.4.20 00:0c:09:f3:f9:e2

There is a configuration file - /Library/Preferences/SystemConfiguration/com.apple.Boot.plist. Take a look at that, and now change that file to the following, under sudo mode -