Re: Hello Debugger/Goodbye Machine
Re: Hello Debugger/Goodbye Machine
- Subject: Re: Hello Debugger/Goodbye Machine
- From: Derek Kumar <email@hidden>
- Date: Thu, 9 Mar 2006 20:00:54 -0500
On Mar 9, 2006, at 7:39 PM, Eric Long wrote:
Where can I find instructions to configure for Firewire debugging?
There is a document included in the kernel debug kit, as well as a
kext to permit debugging over FireWire.
Ok. I downloaded Kernel_Debug_Kit_10.4.5_8H14.dmg. The only document
inside is "Kernel Debug Kit Read Me.html". It doesn't contain the
word
Firewire. None of the documents it points to via links seem to
tell either.
This is actually in the FireWire SDK, which you can download at:
http://developer.apple.com/sdk/
The components of interest would be:
FireWireKPrintf - High speed logging that hooks into kernel kprintf()
output.
FireLog - High speed logging, faster and more flexible than
FireWireKPrintf.
FireWireGDB - Special-purpose debugging over FireWire.
FireWireKDP - Remote interactive Kernel debugging over FireWire.
FireWireCoreDumper - kernel coredumps over FireWire
(All of which are useful if you're doing early debugging, or if the
network is unavailable for some other reason).
Yes. You must explicitly symbolicate your kext,
I have been using: sudo kextload -s /tmp /tmp/MyKext.kext
The KDH Read me has this tidbit:
" This package now includes the createsymbolfiles script which
simplifies
creating symbol files for kernel debugging. Run this script as
follows:
$ /Volumes/KernelDebugKit/createsymbolfiles -s
<symbols_directory>
<KEXT_to_load>"
So evidently there is a useful tool there, but since it doesn't
explain it's
utility over simply using kextload -s, I don't know what it really
does.
This appears to be a script which wraps kextload to use /Volumes/
KernelDebugKit/ as the source of the kernel image and kext
repository, among other things. Easier than passing lots of flags to
kextload, I'd imagine.
So, unless it's the boot volume, I assume this means the source paths,
including volume name, must match, at least with the aid of a
symbolic link.
Yes. Also, the SO stabs embedded in the kernel image supplied with
the kits contain paths of the form:
/SourceCache/xnu/xnu-792.6.56/bsd/vfs/vfs_syscalls.c
(as with open() for instance)
If you install the kernel sources, and create the appropriate
SourceCache symbolic link, you can also examine kernel sources while
debugging with gdb.
Derek
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden