Messages in this thread | | | From | "J. Dow" <> | Subject | Re: Availability of kdb | Date | Thu, 7 Sep 2000 22:27:31 -0700 |
| |
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/
| |