What version of lldb are you using? This looks like it should work - Xcode 5.x's lldb is definitely expected to work, earlier releases may not (I can't remember exactly when the kernel core file debugging support was fnished - but I think Xcode 5's lldb was the start of it).
When lldb starts examining a core file, it searches for a kernel binary in the core file. If it finds one, it switches from "user debug" to "kernel debug" mode (specifically - it selects the DynamicLoader and Platform plugins for kernel debugging).
Once you've checked that you're using a recent lldb (e.g. lldb-310.2.x for the latest Xcode 5.x update), you can try running lldb on the core file directly without specifying the kernel binary as a test -
% lldb -c core-xnu-blahblahwhatever--53821b67
Kernel UUID: 9FEA8EDC-B629-3ED2-A1A3-6521A1885953
Load Address: 0xffffff802c400000
When you see the Kernel UUID:
and Load Address:
lines, that tells you that lldb found a kernel image in the core file. You can also use the platform status
command to confirm which platform is selected:
(lldb) pla sta
Platform: darwin-kernel
Connected: no
Debug session type: Mac OS X kernel debugging
Kext directories: [ 0] "/System/Library/Extensions"
Kext directories: [ 1] "/Library/Extensions"
Kext directories: [ 2] "/Applications/Xcode.app/Contents/Symbols"
Total number of kexts indexed: 818
(lldb)
Of course you can't do real kernel debugging without the kernel binary - just a quick tip, you can specify the core file and the binary on the command line,
% lldb -c core-xnu-blahblahwhatever--53821b67 /Volumes/KernelDebugKit/mach_kernel
The addresses in your backtrace look like a kernel core file session, but for some reason the lldb you're using isn't finding the kernel in there.