Re: Hello Debugger/Goodbye Machine
Re: Hello Debugger/Goodbye Machine
- Subject: Re: Hello Debugger/Goodbye Machine
- From: Terry Lambert <email@hidden>
- Date: Thu, 9 Mar 2006 16:54:23 -0800
On Mar 9, 2006, at 4:39 PM, Eric Long wrote:
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.
You have to have the developer tools installed.
/Developer/Extras/Kernel Debugging/README:
=========================================
KDP Debug over FireWire
-----------------------
AppleFireWireKDP enables gdb kernel debugging over a FireWire cable. It
provides the following advantages over Ethernet debugging:
* Available much sooner in the kernel's startup.
* Available until right when the cpu is powered down at sleep and
almost as
soon as the cpu is powered when waking.
* No IP network configuration is required.
There are two components: AppleFireWireKDP.kext that resides on the
target
machine, and FireWireKDPProxy which runs on the host debugger machine.
[ ... ]
=========================================
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.
It's a bourne shell script - it's readable as a list of command line
comaands that gets executed when you run it.
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.
Yes.
-- Terry
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