site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thank you Terry for this great infos. Am 02.06.2007 um 05:00 schrieb Terry Lambert: The kernel debugging that you are trying to use is based on: (1) having a polled mode driver (2) being able to talk to that polled mode driver with a gdb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGYYlaBDxoGUAtYxoRAt8fAKCsNnz81S7ejSOgHFpOZqhCXh+IUwCgn2hl KXXNUSvVZFzOKF7xicsUoqQ= =g86h -----END PGP SIGNATURE----- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... I put right after the delay you mentioned a PE_enter_debugger ("debug_me") which works fine, the problem at this point now is the kernel does not find a mac/ip address to use. Which nic's mac address is commonly used? The primary interfaces one? On Jun 1, 2007, at 3:34 PM, apic | puredarwin.org wrote: Thank you for your answer. I now can successfully have the kernel break at the desired point but now comes a further problem into play. I cannot make the kdg to jump on the train of a serial port, also I cannot figure how one would attach to a remote-kdg target via the serial port. This case is more problematic than usale as I have no chance to load any network driver and do debugging via a network connection of any kind. The docs previously posted mention there is this possibility but I can hardly find any docuemnt discribing the serial line approach. This is not supported. The serial debugger is not a gdb based debugger, and it only works if you build your kernel DEBUG and set flags. There's no way to symbolically debug via serial port. Theoretically, you could hack up gdb to support this, and then you could hack up a serial driver that registered itself as the driver to use when you break to the debugger, but then you are in exactly the same boat as before, where you need to load the KEXT. What you need to do is follow the instructions (in the kernel debugging tech notes) so that BootX loads the KEXT for you, by telling it the KEXT is necessary to mount the root device in safe mode; this will get the debugger KEXT loaded early, but you will still need to get it to register itself before you can debug the kernel that way. This basically means that the earliest you can reasonably expect to get to a gdb is in bsd_init(), just prior to it calling inittodr() - and that's exactly where you will see where we, when we are working on the kernel, start our early debugging (there is a small "#if 0" section that you change to a "#if 1" to enable early debugging). Other than that, you are stuck with the built-in serial debugger, unless you have hardware like a JTAG or ITP. Am 01.06.2007 um 22:00 schrieb Herb Petschauer: Put a PE_enter_debugger() call into your start() method? This is frequently not enough, since you have to wait for things to settle to ensure the debug transport device is registered, etc., before jumping into the debugger. That's why the commented out block in bsd_init() has an IOSleep() for 10 seconds. -- Terry This email sent to site_archiver@lists.apple.com