From: "Horst von Brand" <vonbrand@inf.utfsm.cl>
> "J. Dow" <jdow@earthlink.net> said:
>
> [...]
>
> > The point is that WITH a debugger you have to take that step as well.
> > A person without the self discipline to do that is still a child and should
> > not be in this business. The debugger gives you a better picture of what
> > is actually happening. If that leverage is considered to be a bad thing
> > I am surprised and dismayed. A bloody LOT of personal experience
> > and technological bloody noses suggests it is a very good thing.
>
> This is true as long as the debugger hooks have no (or very minimal) impact
> on the instrumented system. Impossible (or very nearly so) in the case of a
> massively parallel program like the kernel. Where it is possible it has
> been done, in general. General hooks into the distributed subsystems inside
> the kernel are only a bit easier to maintain than the instrumented code,
> and they impact its performance, stability and readability.
Oh bat doodoo. In the first place you use a debug build with the debugger
built in for debugging. You run a real build without the debugger for
production. In the second place since you have the sense to do the
aforementioned good practice you keep in mind that there are interactions
involved to indicate whether the problem goes away or not and how the
problem manifestation changes with the debugger present. In the third
place if you are reduced to printk you can have even worse timing issues
than with a well constructed debugger.
If you have that well constructed debugger you have a patch to install it.
If there is a "make debugged" and "make nondebugged" command in
the kernel Makefile and the debugger is not patched in for most people
until they issue the "make debugged" command you have exactly what
you have now with the addition of a debugger for which there is a huge
incentive to maintain it.
Heck, run up proposed patches in the debugger, confirm your desk
analysis of what they do, THEN install the patches into the kernel
formally. (And for Ghu's sake make it a source level debugger if you
want it to work right.)
> You did not build a logic analyzer and circuit simulator into each and
> every transmitter you built, did you?
I built in the test points these tools attached to in each and every module
of each and every radio. Except obviously the simulator was used before
hand to predict circuit performance. If you design for proper testpoints
there is little or no affect on operation and a great improvement in ease
of maintenance and tuneup.
> I've used debuggers too, and do so sometimes to check on stuff I write when
> I'm truly stumped, but in general I stay away from them. I (try to) write
> stuff in modular, cleanly separate parts with (I hope) well understood
> interactions. That makes isolating bugs easy enough without a detailed
> step-by-step following of the program, at least most of the time. Debuggers
> _can_ be useful, no question about that. But you can also waste a huge
> amount of time with them. They just give you _one_ very narrow picture of
> what is going on, and that picture is from a quite useless perspective most
> of the time.
That design approach plus a good debugger can reach the finished line
of clean completed and debugged (to the same level) code quicker than
without the good debugger. The times I have most loved the debugger are
when the code generated is very different from the code laid down either
due to a typo I continually overlooked (I am human - I think) or a compiler
bug. Sometimes it actually adds time to development if I didn't NEED to run
that debugger based verification that what I intended is what appeared.
(Sadly I don't quite have the self-discipline to make that run EVERY time
and even worse sometimes I have not had the debugger to work with.)
So far I have noticed that the debuggers catch a wider range of issues
than the desk analysis.
{^_^}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:10 EST