Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!think!ames!oliveb!pyramid!prls!mips!djl
From: djl@mips.UUCP (Dan Levin)
Newsgroups: comp.unix.wizards
Subject: Re: Debugging the kernel: proper methods?
Message-ID: <479@winchester.UUCP>
Date: Mon, 22-Jun-87 14:58:18 EDT
Article-I.D.: winchest.479
Posted: Mon Jun 22 14:58:18 1987
Date-Received: Tue, 23-Jun-87 06:41:15 EDT
References: <2713@uw-june.UUCP>
Lines: 28
Summary: Depends on Your System, Now Doesn't It?

In article <2713@uw-june.UUCP>, randy@uw-june.UUCP (William Randy Day) writes:
> Is there a proper method for debugging kernel routines?

Well, it all depends on what facilities you have available.

When I want to debug my kernels here at MIPS, I crank up our version of
dbx that understands how to debug running kernels. Then I put a breakpoint
in the interesting routine, and use standard symbolic tools to analyze
whatever I am interested in.

In past lives, I have spent a fair amount of time hunched over a hex symbol
table running a PROM level debugger under a kernel.  You need a
disassembly of the routine you want to examine, but most machines provide
some type of PROM debugger that lets you step through code. Just put a
breakpoint in the routine in question, and away you go.  Sometimes you
need to put a special instruction (like a brk or some kind of intr) in
to drop you into the debugger.  You can use adb to patch it into the
routine in question.

A final, and very painful, technique, is to use printf()'s.  It helps if
you have a method for controlling which printf()'s are enabled at any given
time, otherwise you get reams of stuff off the console.  Note that printf()'s
are sometimes the only way to get context on a problem...

-- 
			***dan

decwrl!mips!djl                  mips!djl@decwrl.dec.com