Date: Sat, 21 Nov 1998 10:25:43 -0800 From: "David O'Brien" <obrien@NUXI.com> To: Paolo Di Francesco <paipai@tin.it> Cc: freebsd-sparc@FreeBSD.ORG Subject: Re: Emulators, and Simulators Message-ID: <19981121102543.A24015@nuxi.com> In-Reply-To: <19981120133755.OPSK21309.fep01-svc@winworkstation>; from Paolo Di Francesco on Fri, Nov 20, 1998 at 02:39:54PM %2B0000 References: <19981120133755.OPSK21309.fep01-svc@winworkstation>
next in thread | previous in thread | raw e-mail | index | archive | help
This from a friend that has done kernel work at Sun and Auspex on SunOS
(he currently does kernel work on HP-UX where he uses simular techniques,
and is now playing with {Open,Net}BSD)
> Another idea: someone ad Sun can tell us if they use two machine to develop
> kernel, and how to do this?
Use kgdb. All of the BSD's have it, but I've found the OpenBSD version to
be incomplete. I'm using the NetBSD version to fill in the pieces. One of
the the kernel hackers that I worked with a Sun did the NetBSD version and
it was brought over to OpenBSD. Not sure why it all isn't in OpenBSD.
> Can we use an Intel box to monitor via the OBP and a serial port?
There is a kgdb <--> OBP interface but my experience at Auspex with
a similar one leads me to recommend to just use OBP to debug the kgdb stub.
> Can we do the memory dump of a "dead" UltraSparc when it does not boot
> correctly?
kgdb can handle this.
> How to implement a mechanism which dump the memory "somewhere" when we
> have a kernel panic?
Forget about dumping memory. Just start with a simple kgdb stub, get it
solid, and build up a solid kernel from there.
Once you have a serial interface working with kgdb you can consider
getting fancy and using a Ethernet interface and really fly.
--
-- David (obrien@NUXI.ucdavis.edu -or- obrien@FreeBSD.org)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-sparc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981121102543.A24015>