Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!ucla-cs!zen!ucbvax!hplabs!pyramid!prls!mips!mash
From: mash@mips.UUCP (John Mashey)
Newsgroups: comp.unix.wizards
Subject: Re: Debugging the kernel: proper methods?
Message-ID: <503@winchester.UUCP>
Date: Tue, 7-Jul-87 16:01:30 EDT
Article-I.D.: winchest.503
Posted: Tue Jul  7 16:01:30 1987
Date-Received: Fri, 10-Jul-87 06:48:05 EDT
References: <2713@uw-june.UUCP> <479@winchester.UUCP> <7224@mimsy.UUCP> <3168@felix.UUCP> <527@saturn.ucsc.edu>
Reply-To: mash@winchester.UUCP (John Mashey)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 29

Sigh.  Once again, it sounds like a shoemakers' children have no shoes
[with exception, so far, of Michael Meissner's note on DG debug envrionment.]
Despite all the talk of CASE, productivity tools, etc, it's sad to
find that people are still using adb, printfs, etc.  In particular,
when you're debugging things that UNIX has now gotten to, this is
nontrivial.  We did something like what Michale described, only a little
more maybe:

Before we'd even gotten silicon, we had the following:
1) a program that turned MIPS object code into VAX object code,
so it would run at a reasonable rate of speed.
2) a dbx variant that would deal with the results of 1), so you could
think you were actually dealing with a MIPS machine.

3) an instruction-level simulator, for debugging bootproms, kernels, etc.
4) a dbx variant that talks to 3).

after we got hardware, we ended up with:

5) a dbx variant that can download a kernel or standalone across
Ethernet onto a testbed, along with a debug monitor that talks
to the dbx across a serial link.

After you you get used to this, there is simply no going back.
-- 
-john mashey	DISCLAIMER: 
UUCP: 	{decvax,ucbvax,ihnp4}!decwrl!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086