Re: ksyms for kgdb

Theodore Ts'o (
Mon, 9 Oct 1995 17:36:42 -0400

From: Mike Kilburn <>
Date: Sun, 8 Oct 1995 13:21:14 +0200 (SAT)

> While I have a lot of respect for Linus, I think this attitude is
> insane. Debuggers are not a panacea for poor program design. But in
> the hands of a good programmer, a debugger can be an extremely
> powerful tool. As with all tools, a debugger is only as good as the
> person using it.

I agree with you on that point. No offense to Linus. But what I have
seen is some people get so dependent on debuggers and logic analyzers
their program designs start to get sloppy. Then, when they get a project
where the debugging tools are not available they cant cope with it. This
increases the cost of development because anytime you want to use a
different cpu or OS for something you have to provide the programmers with
all the debuging tools or they start whinging, even if it a simple one-off
project. As you said it depends on the person, but I wont hire someone that
cant work without a debugger. Reading the source to find is something every
programmer should be able to do.

I definitely agree with you that every good programmer should be able to
work without a debugger. However, a debugger can really speed up the
time it takes to track down and fix a problem.

I recently finished writing a device driver for a BSDI system, and the
fact that they had a real kernel debugger made the development go much,
much faster. I had been working with Linux for so long that, when I
finally got back to an environment where there was a kernel debugger, it
was like being forced to use /bin/ed for a long time, and then suddenly
being allowed to use emacs (or vi) again. True, emacs is not
_necessary_; but it certainly makes things go much faster.

The feature that was definitely the most helpful was crash dumps. Often
times, simply knowing the stack trace isn't enough. Being able to run a
debugger and take a look at several structures, pointers, etc. is just
very, very, very convenient.

I'm thinking that it might be useful to define an interface to certain
block devices which allow you to do I/O that bypasses the buffer cache,
for the express purposes of allowing crash dumps to be written to some
contiguous area of disk (probably a swap partition). The bounds of the
crash dump area could be calculated in advance, and stored somewhere
safe; this would reduce the amount of code that the crash dump routines
would have to depend upon. (And, you really don't want to touch the
buffer cache at all while you're doing the crash dump, lest that disturb
valuable evidence about What Went Wrong.)

I probably won't have time to take on this project in the near future,
but if someone else, let me know..... I'd be glad to serve as a someone
to bounce design ideas off of, and to be a beta tester.

- Ted