Date: Sun, 8 Apr 2001 17:50:54 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Greg Lehey <grog@lemis.com> Cc: FreeBSD-arch@FreeBSD.ORG Subject: Re: Making ddb a kld Message-ID: <Pine.BSF.4.21.0104081741480.70807-100000@besplex.bde.org> In-Reply-To: <20010408113054.L76422@wantadilla.lemis.com>
index | next in thread | previous in thread | raw e-mail
On Sun, 8 Apr 2001, Greg Lehey wrote: > >> 1. We often get people who say "my system crashes. Why". On > >> checking, there's no practical way to determine why, because they > >> don't have a debugger in the system. > > > > They can run gdb if they have a panic dump. > > If they have a panic dump and a kernel with symbols. You'll recall > that all attempts of mine to get the latter as default have been shot > down in flames. All kernels have symbols (non-debugging ones, the same that ddb has). > Consider following scenario, on a production machine. Machine works > fine for months, then starts crashing. Remote support dials in, loads > the ddb module into the running system, then waits. When the machine > crashes, remote support dials in again and debugs via serial > interface. > > Not the best way to do things, admittedly, but one that some people > like to do. To quote one respected member of our community: Remote support dials in, builds a kernel with ddb and possibly other debugging code configured, and reboots to the new kernel (or just install it and wait for a crash to reboot to it). > > I normally use ddb anyway -- gdb takes too long to start up and > > doesn't work well for low-level stuff. > > >> 2. Occasionally it's convenient to look at what's happening in a > >> running system. Admittedly, you have to freeze the system to use > >> ddb, but it can be of use. > > > > Again, it is better to always configure ddb, in case you need it to > > look at what's happening on a hung system that can't load a module. > > Then we should make it part of the default kernel. But there will > always be cases where one particular debugging method doesn't work. > That doesn't disqualify it completely as a method. It would just be bloat and a security hole for most people. > >> Con: > >> > >> 1. This will require moving all the ddb code, which is scattered > >> around the system, into a separate file. I'm prepared to do the > > Version mismatch problems are another issue, one which we should > address. They don't belong in this discussion. But I thought that > ddb would recover from that kind of error, just as it does if you try > to display the contents of unmapped memory. I had forgotten about that. Yes, it should recover, provided ddb doesn't use any locks (longjmp'ing out of the trap handler would leave the locks active). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the messagehelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0104081741480.70807-100000>