debugStub not catching kernel panics or manual int3s

[mothball187]

Hello all,

I am trying to debug a kext I am building that is causing panics. I am running the same version of 10.12.4 (Sierra) on both my host and VM guest. Using debugStub.listen.guest64 = "TRUE" in my config file, I am able to connect lldb from my host to my guest with the gdb-remote command. I can manually break with ^C and I can set breakpoints with no problem, everything works as expected. However, when there is a panic, the VM reboots without the debugger ever getting a chance to catch it. I tried to work around this by setting manual breakpoints in my code with __asm__("int $3"), but this just causes the VM to reboot like a panic and the debugger still does not catch it. Any help or insight would be greatly appreciated, thank you!

[dariusd · Accepted solution]

"manual" int3s inside the guest are not caught by debugStub because they are purely a guest operation.  The guest OS can use int3 for whatever purpose it desires beyond interactive debugging, and it would not be appropriate for the debugStub to consider each one a breakpoint.  Similarly for a guest panic, which is really just a sequence of guest operations containing nothing to grab the attention of the debugStub.

I think your best option is to load the guest kernel symbols into lldb, and set a breakpoint on panic().  That will force your debugger to break for any call to panic(), direct or indirect, including int 3.

Cheers,

--

Darius

[mothball187]

Thank you for your insight and the tip to break on panic()!