Re: Hello Debugger/Goodbye Machine
Re: Hello Debugger/Goodbye Machine
- Subject: Re: Hello Debugger/Goodbye Machine
- From: Eric Long <email@hidden>
- Date: Thu, 09 Mar 2006 16:39:46 -0800
> You need to disable the kext so that the driver didn't load and the
> hardware is not discovered by the OS.
Ok. I assume that means removing AppleAirPort.kext and AppleAirPort2.kext.
>> 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.
> 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.
> and the sources must
> be in the same relative location.
> Generally, if I'm doing developement on multiple machines, I put the
> stuff near the root of a volume, and then on the debugging machine,
> after I copy things over, I create a symbolic link to make sure the
> same path resolves to the same files there.
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.
Eric
_______________________________________________
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