From owner-freebsd-hackers Thu Aug 19 19: 3:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 0D8391518D for ; Thu, 19 Aug 1999 19:03:12 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (cs1-gw.cs.binghamton.edu [128.226.171.72]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with SMTP id WAA01530; Thu, 19 Aug 1999 22:01:20 -0400 (EDT) Date: Thu, 19 Aug 1999 21:48:00 -0400 (EDT) From: Zhihui Zhang To: Greg Lehey Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel debugging questions In-Reply-To: <19990820093530.G14964@freebie.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 20 Aug 1999, Greg Lehey wrote: > You can't control the execution of the kernel, you can just look at > the way things are. With the core dump, you at least have the > advantage that things won't change while you look at them; you can't > even do that with /dev/mem. The other alternative is remote serial > debugging, where you *can* influence the execution of the kernel, for > example by setting breakpoints. But remember that the kernel is > already running when you attach to it, so you don't say 'run', you say > 'c[ontinue]'. Thanks for your response. I can not think of those points myself. However, on page 7 of the book "Panic! Unix system crash dump analysis", it says that a debugger named kadb in SunOS can load the real kernel during boot and treat the latter like a great, big, user program, stepping through its execution, examining and modifying values on the fly. It seems to me that FreeBSD does not have such a debugger. Maybe ddb can do so, but it works with assembly. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message