Linux Today: Linux News On Internet Time.

More on LinuxToday

Keith Owens: The case for a standard kernel debugger

Sep 13, 2000, 23:04 (17 Talkback[s])
(Other stories by Keith Owens)


Desktop-as-a-Service Designed for Any Cloud ? Nutanix Frame

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

(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?


Related Stories: