[cgl_discussion] Project Review: kdb

Andy Pfiffer andyp at osdl.org
Tue Sep 10 16:42:00 PDT 2002

1. Quote the requirements from the reqruirements doc
   that your project is expected to meet.

2. Explain how you think the project meets the
   above requirements.

3. Explain the design of the project or point to
   a document on the web that explains the design.

4. Pointer to the code/patch.


1. Quote the requirements related to the kernel debugger.

Category: Tools
  Requirement: 5.3 Kernel Debugger

	OSDL CGL shall support a kernel debugger that provides
	the ability to break into a running kernel at boot time
	or during system operation, set breakpoints, examine memory
	contents in several formats, change memory contents or
	machine registers, and other debug functionality.
	The debugger shall be SMP-aware. It can support remote
	kernel debug sessions on headless systems using a
	tty connection.

	Support can be configured out if desired.

2. Explain how the project meets the requirements.

	The code already present in the tree is an integration
	of kdb v2.1:

		Built-in Kernel Debugger for Linux - v2.1

		This debugger allows the programmer to interactively
		examine kernel memory, disassemble kernel functions,
		set breakpoints in the kernel code and display
		and modify register contents."

	All functionality listed in the CGL requirment is advertised
	as being present in kdb v2.1.

3. Point to a document on the web that explains the design.

	Overview: http://oss.sgi.com/projects/kdb/index.html
	FAQ: http://oss.sgi.com/projects/kdb/faq.html

	Additional documentation (in CGLE CVS kernel repository):

	  Overview manpage (man format):

	  Breakpoint commands (man format):

	  Stack traceback commands (man format):

	  Environment manipulation commands (man format):

	  Linked list examination (man format):

	  Memory manipulation (man format):
	  Register manipulation (man format):

	  Single Step (man format):

	I have configured, built, and run a kdb-equipped
	CGLE kernel.  I performed some basic interactive
	testing, and could: break into a running system,
	set breakpoints, examine memory contents, and change
	memory contents, and perform stack tracebacks.

	I have not tried:
	1. instruction disassembly
	2. headless operation with an RS232 line.

4. Pointer to the code/patch.

	Open-source project page:

	Two patches present in the CGLE CVS kernel repository:

	One patch is for generic kernel support, the second for
	IA32 architectures.

More information about the cgl_discussion mailing list