Debugging kernel code

Question

Created Jun ’20

Replies 2

Boosts 0

Participants 2

I've noticed that breakpoints don't always work when debugging kernel code (kexts).

Is there something special that needs to be done for them to work reliably?

Also, sometimes the target hangs while debugging.

The panic log says something like "mpkdpenter() timed-out during locked wait after NMI;" "expected 8 acks bug received 7 ..."

boot-args does include watchdog=0 and pmuflags=1

This is on Big Sur.

Thanks.
Devendra.

Boost

Answer 1

jingham OP

Jun ’20

First, make sure the breakpoints have been resolved to some actual address. Use the break list command, then check to make sure the breakpoints have locations and are marked as "resolved". If that's not true then for some reason we weren't able to find any locations in code that matched your breakpoint specification.

The other thing to watch out for, if you are building your kext with optimization on, is that optimization often changes ordering of execution, and sometimes the line tables don't track that accurately. I've seen cases, for instance, where a breakpoint on the line of an "if" test or "switch" gets moved inside the switch, so that it won't get hit 100% of the time. You can often work around this by moving the breakpoint a little earlier in your code.

1

Answer 2

dparakh OP

Aug ’20

Thanks for your reply

The break list indeed reports that the breakpoints have been resolved to addresses.
[A dissasembly of those addresses indicates the right code is involved].

This was done in debug builds, with optimization off.

0