How to debug kernels (was: cvs commit: src/sys/conf kern.post.mk)

[Ben Kaduk]

On 9/12/05, Greg 'groggy' Lehey <grog at freebsd.org> wrote:
> 
> On Saturday, 10 September 2005 at 22:29:02 -0400, Kris Kennaway wrote:
> > On Sat, Sep 10, 2005 at 10:01:15PM -0400, Garance A Drosihn wrote:
> >> At 6:05 PM -0700 9/10/05, Nate Lawson wrote:
> >>> David E. O'Brien wrote:
> >>>> obrien 2005-09-11 00:22:21 UTC
> >>>>
> >>>> FreeBSD src repository
> >>>>
> >>>> Modified files:
> >>>> sys/conf kern.post.mk <http://kern.post.mk> Log:
> >>>> For HEAD, install a kernel with debug information if DEBUG is a 
> kernel
> >>>> config option. It is too easy to loose the build directory and not 
> have
> >>>> symbols for kgdb to read.
> >>>> Revision Changes Path
> >>>> 1.84 +4 -17 src/sys/conf/kern.post.mk
> >>>
> >>> I disagree with this change. We do not need to waste the space
> >>> in /. If I'm running a debug kernel, it is based on the latest
> >>> version of kernel.debug in my kernel compile dir and I know to
> >>> find it there.
> >>
> >> Fwiw, I've been burned by building a debug kernel, only to have
> >> removed the original compile-directory for that kernel by the time I
> >> actually *needed* the debug symbols. It's one thing if you're building
> >> a debug kernel because you know you're going to spend the next hour
> >> debugging some change. It's another if you're building a debug kernel
> >> because your machine might panic sometime in the next two or three
> >> weeks.
> >
> > Likewise, I also find this change very useful. When I'm juggling a
> > few dozen panics on a few dozen machines with a few dozen different
> > customized source trees, it's hard to keep track of all the
> > kernel.debugs. Now I don't have to.
> 
> A lot must depend on how you use your debug kernel. One of the
> biggest problems I've found is keeping the kernel and the sources in
> sync. This change makes it more difficult. Also, the kernel build
> can install debugging macros in the build directory; if you blow away
> that directory, you've lost the macros too.
> 
> The method I use is described in
> http://wwww.lemis.com/grog/Papers/Debug-tutorial/tutorial.pdf.
> Basically, you debug from the kernel build directory and just pull in
> the dump from /var/crash. I'm planning to present it again in Basel
> in November, so if anybody disagrees with the approach, now is the
> time to tell me. With this method, having symbols in the booted
> kernel is a waste of time and space.
> 
> Greg
> --
> See complete headers for address and phone numbers.
> 
> 
> 
Somewhat of a side point, but what do people think of doing a similar thing 
for loadable modules? I am actually quite ignorant about the matter, not 
even knowing if a DEBUG=-g line in a kernel config file propogates to 
modules built at the same time (I should think it would), but the same 
situation can occur for modules as for the core kernel.

In fact, I just today needed snd_ich.ko.debug, but very nearly blasted it 
away with a buildworld/buildkernel, since I want to check if the panic I get 
has been fixed in the past week. Luckily, the need to save such a file was 
pointed out to me quickly, but (as a fairly ignorant end-user), it may make 
it possible to solve a problem reported by the same.
This of course magnifies the space requirement, and deciding which modules 
to include could be a big bikeshed, but if the debug kernel on / stays, it 
should be thought about.

Ben Kaduk