Skip to content
This repository has been archived by the owner on Feb 16, 2020. It is now read-only.

KernelDebugging

Jump to bottom
Alex Blewitt edited this page Mar 7, 2010 · 11 revisions
  1. summary How to debug with a two-machine setup
In order to do any kind of debugging on the Mac OS X ZFS implementation, you need to be able to set up a secondary machine in order to debug into the code. This explains how to set up such a system.

Requirements

You need two machines, both running exactly the same version of OSX (e.g. 10.5.8 and 10.5.8, or 10.6.2 and 10.6.2). It helps if they're the same architecture, but this isn't strictly necessary.

You'll need to download the OSX Kernel Debug SDK for the OS version you're currently using/targeting. When mounted, it will show up as `/Volumes/KernelDebugKit` for whatever version you're using.

You need a mechanism for transferring files between the two computers. One way of doing this is to export a common directory over NFS; another is to use `rsync`. For the purposes of this document, I'll assume that you have a directory `/target` and that the machine is called `target` as well, so that `rsync -cav . target:/target` will copy your files across.

You need to have enabled your target box to go into a debug state upon a kernel panic, or upon the power button being depressed (usually used to put the machine to sleep). This only needs to be done once per machine, since it's stored in hardware status. 

  # `sudo nvram boot-args="debug=0x14e"`

Steps 

  # `cd /path/to/maczfs`
  # `rm -rf build`
  # `xcodebuild -configuration Debug`
  # `cd build/Debug`
  # `rsync -cav . target:/target`
  # `ssh target sudo chown -R root:wheel /target`
  # `ssh target sudo kextload -s /target /target/zfs.kext`
  # `rsync -cav target:/target/*.sym .`
  # `gdb -arch i386 /Volumes/KernelDebugKit/mach_kernel`

The debugger can be set up as follows: 

  # `source /Volumes/KernelDebugKit/kgmacros`
  # `target remote-kdp`
  # `add-kext zfs.kext`

You're now good to go with debugging. You can attach to the remote target, print out the frame, and then debug to your heart's content. 

  # `attach target`
  # ...
  # `kdp-reboot`

If you want to cycle through running test cases, you'll need to add `/target` to your `PATH` and `DYLD_LIBRARY_PATH` variables. This is easy to do with `env` when running cases: 

  # `ssh target env PATH=/target DYLD_LIBRARY_PATH=/target zpool scrub`

References 

  * [http://developer.apple.com/mac/library/DOCUMENTATION/Darwin/Conceptual/KEXTConcept/KEXTConceptDebugger/hello_debugger.html Kext debugging] from developer.apple.com
  * [http://developer.apple.com/mac/library/technotes/tn2002/tn2063.html TN2063] understanding kernel panic logs
  * [http://developer.apple.com/sdk/ Kernel Debug SDKs] for your operating system
  * [http://blob.inf.ed.ac.uk/sxw/2010/01/17/debugging-a-mac-os-x-kernel-panic/ Debugging a kernel panic] by Simon, which suggests that a EDX containing 0x0 is symptomatic of a null dereference.
Clone this wiki locally