How to debug kernels (was: cvs commit: src/sys/conf
kern.post.mk)
Ben Kaduk
minimarmot at gmail.com
Sun Sep 11 23:26:50 PDT 2005
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
More information about the cvs-src
mailing list