Date: Sun, 8 Apr 2001 11:30:54 +0930 From: Greg Lehey <grog@lemis.com> To: Bruce Evans <bde@zeta.org.au> Cc: FreeBSD-arch@FreeBSD.ORG Subject: Re: Making ddb a kld Message-ID: <20010408113054.L76422@wantadilla.lemis.com> In-Reply-To: <Pine.BSF.4.21.0104071718190.62414-100000@besplex.bde.org>; from bde@zeta.org.au on Sat, Apr 07, 2001 at 05:37:27PM %2B1000 References: <20010406150129.O66503@wantadilla.lemis.com> <Pine.BSF.4.21.0104071718190.62414-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, 7 April 2001 at 17:37:27 +1000, Bruce Evans wrote: > On Fri, 6 Apr 2001, Greg Lehey wrote: > >> A little over a year, I did some work for Sitara Networks. In the >> course of this work, I made ddb an lkm, in order to be able to load it >> on a production system if needed. >> >> I'm now in the process of merging Sitara's code, which is based on >> 3.2-RELEASE, into RELENG_4. Sitara have generously agreed that we can >> commit any fixes they have in their tree which are not vital to their >> commercial interests. The ddb mods would be one of them. Do we want >> to do this? > > Of course not. > >> The pros and cons I see are: >> >> Pro: >> >> 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. > I have thought of making ddb backtraces for panics a standard part > of the kernel. People shouldn't need to know how to run ddb or ddb > to produce useful crash reports. Sounds good. I'd certainly agree with that. > Having an loadable ddb is not much more useful than having a ddb > option. It will never be there when you need it unless you always > configure it. 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: > 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. >> 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 >> work, but it's possible that somebody would complain about the >> colour of the bikeshed. Here's your chance. > > This would demodularise all the code that is scattered around the > system. Yes, that's what I said. > It would also give the nice version mismatch problems: e.g., ps in > the kernel would tend to panic the whole system where ps in userland > would just panic itself. 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. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010408113054.L76422>