1

I am trying to do remote-kernel-debugging. I am using two VM. I have Leopard OSX 10.9 on both VMs and I also installed KDK(kernel debug kit as per the system version).

On the VMs to be debugged I have used the following instruction to start debugging.. $nvram boot-args="debug=0x141 kext-dev-mode=1 kcsuffix=development pmuflags=1 -v"

Now on VM to be debugged on restart I am getting - "Waiting for remote debugger connection.

And on other machine when i tried to connect with lldb - kdp-remote (ip) . It says KDP_REATTACH failed.

I dont know what is problem. Help needed !!

  • 1
    1. OS X 10.9 is Mavericks, Leopard is 10.5. Which are you using? – pmdj Jul 15 '16 at 09:26
  • 2. What virtualisation environment are you using, and how is your VM network configured? Can you access that IP address from the host (ssh, VNC, whatever) before stopping the VM in the debugger? – pmdj Jul 15 '16 at 09:27
  • Ya. I am using Maverick. And the virtualization env is VMFusion(professional version 8.1.0. Yes, I could ping both the machine from each other when both the OS are up. But when bebug machine rebooted in debug mode, I could not ping from host. Both machines are in same subnet. – hrishikesh chaudhari Jul 15 '16 at 10:33
  • Are you seeing the correct IP address in the "Waiting for remote debugger connection." message? (Either on serial port or on VM screen.) If it's during early boot the VM might not have an IP yet. – pmdj Jul 15 '16 at 12:39
  • ya.. it is showing exact IP and mac address of VM – hrishikesh chaudhari Jul 15 '16 at 12:48
  • Hmm, I wonder if it's an ARP issue. Have you checked if the IP and MAC are in the host's ARP table? (`arp -a`) – pmdj Jul 15 '16 at 12:54
  • Ya .we have DNS controller which might be causing problem. But when i do arp -a ..there it shows mapping of IP and hostname. I will try to connect these vm using bridge and then try possibly. I hope that should work – hrishikesh chaudhari Jul 15 '16 at 13:22
  • There is no solution for me till now. I have tried many things. arp table seems file. The machine to be debugged cannot be pinged ..is it a problem?? – hrishikesh chaudhari Jul 18 '16 at 15:18
  • Have you tried connecting to the debugger on a kernel panic (or `int $3`) instead of on boot? This has always worked for me in VMWare Fusion; I've never tried boot-time debugging, so it's possible that doesn't work. – pmdj Jul 19 '16 at 08:28
  • how to connect debuuger on a kernel panic (or int $3) ? is it related to nvram debug value ?? – hrishikesh chaudhari Jul 20 '16 at 10:01
  • Yes; the 0x0001 bit in your debug value is what causes it to break to debugger immediately after boot. If you remove it (`debug=0x140`) the system will start up normally, and only break into the debugger when there would normally be a kernel panic, or on a breakpoint you've set. You can only set breakpoints once you've already broken into the debugger, so you can add `__asm("int $3");` somewhere in a debug build your kext when you want to enter the debugger. – pmdj Jul 20 '16 at 12:50
  • The other option is to enter the debugger on an NMI (power button press), but those don't work in VMWare Fusion. – pmdj Jul 20 '16 at 12:50
  • Hey thanks for your help. Now I am facing a different problem. – hrishikesh chaudhari Jul 22 '16 at 12:44
  • Hey thanks for your help. Now I am facing a different problem. I have added __asm("int $3) in the code and able to enter into a debugger. Now the problem is what should be set as target in lldb command? I have mach_kernel and also have my own kernel extension. if I set mach_kernel a target I am not able put breakpoint in my kernel extension and if I make target as my kernel ext ..i can put breakpoint but then it says invalid process when i hit continue..... So the question is how to proceed after connecting bebugger in panic mode??? – hrishikesh chaudhari Jul 22 '16 at 12:52
  • Why don't you repost that as a separate question, this has nothing to do with the question above. – pmdj Jul 23 '16 at 11:15

1 Answers1

0

While remote kernel(MAC OSX) debugging make sure that your host machine must be physical one and target machine could be VM. Do not try to do remote debugging on two VMs.