Date: Thu, 27 May 2004 19:55:48 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: David Magda <dmagda@ee.ryerson.ca> Cc: stable@freebsd.org Subject: Re: how to interpret crash? Message-ID: <Pine.NEB.3.96L.1040527194447.74482A-100000@fledge.watson.org> In-Reply-To: <B3C75498-B036-11D8-A04B-000A95B96FF8@ee.ryerson.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 27 May 2004, David Magda wrote: > > You don't need the actual kernel.debug to boot with, just the image > > around > > so when you run gdb -k it can pull the symbols out. Otherwise, the > > installed kernel is stripped. On -CURRENT, there's a > > /sys/$arch/compile/$kernelname.debug that you suck in. > > Yes, but I sometimes clean out my compile / object directory and so when > I need the debugging kernel it's not there (and I may have cvsup'ed my > source tree). It would be nice if a debugging kernel is sitting there > beside the kernel that I booted. I've you've cvsup'd your source tree, the debugging kernel may not be all that useful either, as the goal of the debugging symbols is to provide a mapping from locations in the kernel binary to locations in the kernel source code. If you have the same source code and same config file, there should be little variation in the compiled code and typically building a fresh kernel from the same pieces is sufficient to provide you everything you need. If you've cvsup'd and no longer have the source code for the old kernel, regardless of having debugging symbols, you're in a much worse starting point for tracking down the problem. One important reason that the debugging kernel isn't kept around is space considerations: in -CURRENT, a 5mb kernel will generally be accompanied by a 30mb debugging kernel. Each module with symbols is similarly swollen: the agp module is normally 72k, but with debugging symbols is 368k. It doesn't take too much of that to fill up most root partitions... I don't debate your basic point that on a stable system, you're least likely to find the symbols when you most need them, as the system will run fine for a long time and then run into some edge case, unusual hardware failure mode, or whatever, and given that it's been stable for years, you will find yourself with little debugging recourse. That's where tricks like using nm to track down the symbols, turning on dumps by default, compiling with the necessary DDB bits to generate a stack trace, etc, can come in quite handy. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040527194447.74482A-100000>