debugging kernel drivers

Question

Created Jul ’15

Replies 4

Boosts 0

Views 2.9k

Participants 2

I have experience writing Windows drivers using the Windows DDK and debugging with WinDBG. I am trying to learn to write Mac OS X drivers using the IO Kit, and the information I have found looks like getting a system set up for kernel debugging is a challenge.

1) it appears that there is no graphical debugger like WinDBG on windows - only gdb. The version of gdb packaged with Xcode doesn't even have tui mode (text user interface) mode enabled. Since the xcode debugger is really a wrapper around gdb, why can't it work? Is the debug environment really this primative? Are there debuggers available that are better than using command line only gdb?

2) it looks like there is a tedious procedure to generate the debug symbols for the driver. Why doesn't the compiler generate the needed symbols?

3) I've read that the target and debugger machine most both be running the same OS. Is this really true? The Kernel Debug Kit for the OS you are debugging has the required symbols, why is the client OS relevant? Does this mean if you need to debug on multiple versions of OSX, you have to a client for each?

Answered by gc. in 28317022

The best documentation these days for two-machine kernel debugging is in the Kernel Debug Kit ReadMe file.

The Kernel Debug Kits are available on the Apple Developer Downloads page. You need the Kernel Debug Kit matching the OS X build you're running on the target system that is running your kernel extension.

--gc

Boost

Answer 1

DTS Engineer OP

Apple

Jul ’15

1) it appears that there is no graphical debugger like WinDBG on windows

Correct.

only gdb.

We haven't used GDB for kernel debugging for a while. It's now done with LLDB.

2) it looks like there is a tedious procedure to generate the debug symbols for the driver. Why doesn't the compiler generate the needed symbols?

This is all much easier with modern versions of the system and LLDB.

3) I've read that the target and debugger machine most both be running the same OS. Is this really true?

No.

It seems like you've been reading some out-of-date tutorials; as I mentioned, we haven't used GDB for kernel debugging for some years now (since 10.9 IIRC). Alas, our official documentation hasn't caught up with this change.

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

0

Answer 2

gc. OP

Jul ’15

Accepted Answer

The best documentation these days for two-machine kernel debugging is in the Kernel Debug Kit ReadMe file.

The Kernel Debug Kits are available on the Apple Developer Downloads page. You need the Kernel Debug Kit matching the OS X build you're running on the target system that is running your kernel extension.

--gc

0

Answer 3

mark_h OP

Jul ’15

Thanks, the only documentation I've been able to find is several OS's old. I found a book "OS X and iOS Kernel Programming", published by APress, which only references up to 10.7.

Is it possible to use LLDB/LLVM with versions of MacOSX older than 10.9? I would prefer to target 10.6 (yes, I know it is old), possibly 10.8 as the latest in order to support as many systems as I can.

I've also found a graphical debugger called Affinic Debugger GUI, which is a gui around gdb. Since it just a wrapper around gdb, it seems like it should be possible to set it up to do remote debugging. I'm curious if anyone has tried this.

0

Answer 4

DTS Engineer OP

Apple

Jul ’15

I would prefer to target 10.6 (yes, I know it is old), possibly 10.8 as the latest in order to support as many systems as I can.

You really don't want to do this. Getting a KEXT to build and run all the way back to 10.6 is a pain even if you ignore the debugger issues. Specifically:

There's a code signing inflection point at OS X 10.9. OS X 10.9 requires signed KEXTs and OS X 10.8 won't load KEXTs that are signed. WWDC 2013 Session 707 What's New in Kext Development has the details.
There's a 64-bit inflection point somewhere around OS X 10.8. Mac OS X 10.6 runs on 32-bit hardware, so you have to build a universal KEXT. In addition, OS X 10.7, even though it only runs on 64-bit CPUs, still has machines running K32, so you need the universal KEXT there too. I think we went K64-only with OS X 10.8, but it might have been later.
The K64 transition is covered by WWDC 2009 Session 501 "Managing Kernel Extensions" and 502 "Creating I/O Kit Drivers for Multiple Architectures and OS Versions". I'm not sure if our WWDC video archives go back that far, which is an indication of how tricky this is going to be )-:
Building, loading and debugging KEXTs with the old toolchain (GCC and GDB) is quite painful. The new toolchain (Clang, LLDB, K64-only) is much more pleasant.
The old toolchain is not supported by modern versions of Xcode; moreover, sufficiently old versions of Xcode are not supported on modern OSes. You'll find yourself having to maintain multiple build machines (real or virtual) so that you can build your KEXT for all the environments on which it runs.

If you do go down this path I recommend that you start by building a modern KEXT for 10.9 and later. That way you won't be distracted by compatibility issues as you do your main development. Then, once you have everything working, worry about how to get it built for older systems.

I've also found a graphical debugger called Affinic Debugger GUI, which is a gui around gdb. Since it just a wrapper around gdb, it seems like it should be possible to set it up to do remote debugging. I'm curious if anyone has tried this.

I haven't looked at this but, given my advice above, it's going to be irrelevant unless it also supports LLDB.

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

0