>>>NetBSD actually does load the symbols into memory, and even keeps them
>>>there if you have DDB enabled.
>
>Does it give you anything extra besides source line numbers?

	Basically, GDB over DDB gets you:

	1. Familiar + more powerful interface of gdb. I've got tons of
		nifty gdb macros/scripts I've picked up that help walk
		data structurs in the BSD kernel, and I'm used to all
		the GDB commands. Many GDB commands have no DDB
		counterpart.
	2. If some kind soul with Motif could build ddd for NetBSD/i386
		(yes, this IS a hint!), you can use ddd on another
		machine. ddd has a long way to go reliability wise, but
		it's still *so* much faster to walk and examine complex
		kernel data structures with ddd than any other way I've
		seen (try going around the PATRICIA tree with DDB or
		even gdb).
	3. Post-mortem debugger is the same as the in-kernel debugger.
		This is a win for your sanity.
	4. You have source-level debugging. Winner.

	KGDB is NOT rock solid though. But it's still a big win IMO.
This isn't a slam on DDB -- it just happens that, for my purposes, KGDB
would work better. And I bet it would work similarly for lots of other
people.

	BTW, is there a DDB command to get a kernel to dump core? As
far as I can tell, if DDB is enabled,  panic() enters DDB and you can
never get a core dump.

>>	Ok, I didn't know this. Does this work with KGDB? (and, for that
>>matter, is it just me, or is KGDB not really in the i386 port?)
>
>Is there any documentation on KGDB

	It's very sparse. BSDI's FTP site has a quick-n-dirty instruction
list for getting it up and running on BSD/OS.

>(or a way to do source-level
>debugging of the kernel, even if remotely through a serial port)?

	That's what KGDB does.

								-Craig