Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!sri-spam!mordor!lll-tis!ptsfa!hoptoad!academ!killer!jfh
From: jfh@killer.UUCP (John Haugh)
Newsgroups: comp.unix.wizards
Subject: Re: Debugging the kernel: proper methods?
Message-ID: <1034@killer.UUCP>
Date: Wed, 24-Jun-87 11:00:14 EDT
Article-I.D.: killer.1034
Posted: Wed Jun 24 11:00:14 1987
Date-Received: Wed, 1-Jul-87 06:35:50 EDT
References: <2713@uw-june.UUCP> <479@winchester.UUCP>
Organization: The Unix(tm) Connection, Dallas, Texas
Lines: 23
Summary: Try adding sprintf-like-routines

In article <479@winchester.UUCP>, djl@mips.UUCP (Dan Levin) writes:
> In article <2713@uw-june.UUCP>, randy@uw-june.UUCP (William Randy Day) writes:
> > Is there a proper method for debugging kernel routines?
> 
> 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...

I didn't invent the sprintf idea - John Bremsteller at Pinnacle was the
first I saw to use it.  When he had a problem, he would add these things
he called 'snaps' (like snapshot) to the code.  It was basically a sprintf
that also gave the stacked PS and PC registers.  All this went into a big
ring buffer (64K or so). There were tools for turning snaps on and off as
well as several ways of viewing them.

This way nothing gets on the screen and you can look quite a ways back in
time to find the problem.

- John.

Disclaimer:
	No disclaimer.  Whatcha gonna do, sue me?