Date: Wed, 7 Apr 1999 10:50:38 +0930 From: Greg Lehey <grog@lemis.com> To: Mark Newton <newton@internode.com.au> Cc: archie@whistle.com, ChrisMic@clientlogic.com, gjb@comkey.com.au, questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Debug kernel by default (was: System size with -g) Message-ID: <19990407105038.U2142@lemis.com> In-Reply-To: <199904070048.KAA16506@gizmo.internode.com.au>; from Mark Newton on Wed, Apr 07, 1999 at 10:18:30AM %2B0930 References: <19990407082416.H2142@lemis.com> <199904070048.KAA16506@gizmo.internode.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, 7 April 1999 at 10:18:30 +0930, Mark Newton wrote: > Greg Lehey wrote: > >> You don't need to install the kernel.debug on the root file system. >> The obvious place to put it is in /var/crash. > > Not so sure about that: If you have half a dozen crash dumps in > /var/crash all from different kernels, how do you work out which > one matches the debug kernel you happen to have there too? You name them according to the dump. vmcore.1 gets kernel.1, etc. savecore does this already, but the kernel it saves (without debug symbols) is pretty much useless. > Pity we can't trust the system's state at crash time. It should be > possible to boot from a debug kernel in / without reading the symbol > table, It is. In fact, it's currently the only way. > and copy its symbol table into the crash dump at the time the system > panics. Core dumps could then be, for all intents and purposes, > self-contained. I don't see much advantage in this. When I have a panic, I can take a dump. I need the symbols in core mainly in a running system that I don't want to reboot. > Perhaps savecore could do that. > > Maybe "make install" in /sys/compile/WHATEVER needs to copy two > kernels: One of them is the normal one which ends up in /, and > put a debug kernel into /var/crash like you suggest; make savecore > copy the symbol table from /var/crash/kernel.debug into crash dumps > so that the problem I pointed to in my first paragraph above doesn't > happen. One way of looking at it. On the whole, I think the way to go is to install the debug kernel in the root or boot file system, and by default not to load the symbols. Then savecore can save the kernel along with the dump exactly as it does now, and we'd have the symbols available for dump analysis. >> A number of other people have observed that the current boot loader >> doesn't load the symbols anyway, so you could install /kernel.debug >> only and still run normally. I consider this a deficiency in the boot >> loader, since it should be possible to load the symbols. Of course, >> an alternative solution would be to install /kernel.debug and leave it >> until boot time to decide whether to load the symbols. That would >> have the great advantage that you wouldn't get any mismatch between >> the two kernels. > > Load the symbols when you drop into ddb for the first time. CTRL-ALT-ESC > can bring up the spinner for a moment... Have you investigated the feasibility of doing this? I think it would make more sense to have a userland program which loads the symbols, then calls the debugger. > Anther idea - Is there any reason why symbol table data can't be in > a KLD that's built at kernel build time and left in > /sys/compile/WHATEVER? Just that it's more work. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990407105038.U2142>