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