From the Linux Kernel Mailing List:
From: Keith Owens
To: linux-kernel@vger.kernel.org
Cc: torvalds@transmeta.com
Subject: The case for a standard kernel debugger
This note puts the case for including a kernel debugger in the master
tarballs. These points do not only apply to kdb, they apply to any
kernel debugger. Comments about the perceived deficiencies of kdb,
kgdb, xmon or any other debugger are not relevant here, nor are
questions about how or when debuggers should be activated. I want to
concentrate of whether the kernel should have *any* standard debugger
at all.
If Linus still says "no" to including any debugger in the master
tarball then that will be the end of this thread as far as I am
concerned. I will then talk to distributors about getting a debugger
included in their kernels as a patch. Hopefully the distributors who
want a kernel debugger can then agree on a standard one.
Disclaimer: Part of my paying job is to maintain kdb. SGI want kdb to
be used more widely to benefit from GPL support. More eyes
and hands means better code for everybody.
(1) Random kernel errors are easier to document and report with a
debugger. Oops alone is not always enough to find a problem,
sometimes you need to look at parameters and control blocks. This
is particularly true for hardware problems.
(2) Support of Linux in commercial environments will benefit from a
standard kernel debugger. The last thing we want is each
commercial support contract including a different debugger and
supplying different bug reports. Bug reports on supported systems
should go to the support contractor but some will filter through to
the main linux lists.
(3) Architecture consistency. Sparc, mips, mips64, ppc, m68k, superh,
s390 already have remote debugger support in the standard kernel.
i386, alpha, sparc64, arm, ia64 do not have standard debuggers,
they have to apply extra patches. Some architectures have extra
debugger code in addition to the remote gdb support.
(4) Debugger consistency. Back in 1997 there were a lot of individual
kernel debugging patches going around for memory leaks, stack
overflow, lockups etc. These patches conflicted with each other so
they were difficult for people to use. I built the original set of
Integrated Kernel Debugging (IKD) patches because I contend that
having a standard debugging patch instead of lots of separate ones
is far easier for everybody to use. The same is true of a kernel
debugger, having one standard debugger that all kernels use will
improve the productivity of everyone who has to support kernel
code, no need to learn the semantics of multiple separate
debuggers.
(5) Easier for kernel beginners to learn the kernel internals. Having
worked on 10+ operating systems over the years, I can testify that
some form of kernel/OS tracing facility is extremely useful to get
people started. I agree with Linus when he said
"'Use the Source, Luke, use the Source. Be one with the code.'.
Think of Luke Skywalker discarding the automatic firing system
when closing on the deathstar, and firing the proton torpedo (or
whatever) manually. _Then_ do you have the right mindset for
fixing kernel bugs."
But Linus has also said "The main trick is having 5 years of
experience with those pesky oops messages ;-)". Beginners need
some way of getting that experience. Reading the source from a
cold start is an horrendous learning curve, debuggers help to see
what the source is really doing. Always remember that 90%+ of
kernel users are beginners, anything that helps to convert somebody
from kernel beginner to kernel expert cannot be bad.
(6) I contend that kernel debuggers result in better patches, most of
the time. Sometimes people misuse a debugger, as Linus said
"I'm afraid that I've seen too many people fix bugs by looking
at debugger output, and that almost inevitably leads to fixing
the symptoms rather than the underlying problems."
Does that occur? Of course it does, I have been guilty of that
myself over the years. Is it inevitable? IMNSHO, no. Seven of
the twelve architectures in the standard kernel already have built
in debuggers. Where is the evidence that these architectures have
more bad patches because of the presence of the debuggers?
Even if somebody does submit a patch to fix the symptom instead of
the problem, that alone is valuable information. Fixing the
symptom focuses attention and the associated information helps to
fix the real problem. We get problem patches even without
debuggers (let's not mention the recent truncate problems ;) but
there are enough eyes on the kernel to find problem patches and
remove them. Adding a standard debugger will improve the quality
of some of those eyes at a faster rate.
So how about it Linus? Does any of this change your mind about
including a standard kernel debugger?
Asbestos_underware_mode=ON.