Re: kdb with serial port
Re: kdb with serial port
- Subject: Re: kdb with serial port
- From: "apic | puredarwin.org" <email@hidden>
- Date: Sat, 2 Jun 2007 17:14:34 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thank you Terry for this great infos.
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?
Am 02.06.2007 um 05:00 schrieb Terry Lambert:
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.
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
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
-----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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden