Two-machine GDB debugging between Macs over Ethernet - transaction timed out

Question

I am trying to debug a device driver which is crashing the kernel on a Mac using a remote machine running gdb (trying to follow the instructions here). Both machines are connected to the same network by Ethernet (same router even, and both can access the network). I have also set nvram boot-args="debug=0x144" on the target and restarted.

I then load the kernel extension on the target as usual. On the host machine I start gdb like this:

$ gdb -arch i386 /Volumes/KernelDebugKit/mach_kernel

Once in gdb, I load the kernel macros and set up for remote attachment

(gdb) source /Volumes/KernelDebugKit/kgmacros
(gdb) target remote-kdp
(gdb) kdp-reattach 11.22.33.44

However, the last command then does not make a connection and I get an endless spool of

kdp_reply_wait: error from kdp_receive: receive timeout exceeded
kdp_transaction (remote_connect): transaction timed out
kdp_transaction (remote_connect): re-sending transaction

What is the correct way to get gdb connected to the target machine?

Answer 1

There are a number of ways to break into the target, including:

• Kernel panic, as stated in your answer above.
• Non-maskable interrupt, which is triggered by the cmd-option-ctrl-shift-esc key combination.
• Code a break in your kernel extension using PE_enter_debugger(), which is declared in pexpert/pexpert.h
• Halt at boot by setting DB_HALT (0x01) in the NVRAM boot-args value.

Additionally, you may need to set a persistent ARP table entry, as the target is unable to respond to ARP requests while stopped in the debugger. I use the following in my debugger-launch shell script to set the ARP entry if it doesn't already exist:

if !(arp -a -n -i en0 | grep '10\.211\.55\.10[)] at 0:1c:42:d7:29:47 on en0 permanent' > /dev/null) ; then
    echo "Adding arp entry"
    sudo arp -s 10.211.55.10 00:1c:42:d7:29:47
fi

Someone more expert could probably improve on my bit of shell script.

All of the above is documented in http://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/KernelProgramming.pdf.

Answer 2

The answer is simply to make sure the target has a kernel panic before you try to attach gdb from the host.