From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ddc669e8cf09b24 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-11 06:05:27 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: mcq95@earthlink.net (Marc A. Criley) Newsgroups: comp.lang.ada Subject: Debugger Rant (was Re: How to debug an Ada program) Date: 11 Jul 2003 06:05:27 -0700 Organization: http://groups.google.com/ Message-ID: <254c16a.0307110505.463b1cc0@posting.google.com> References: NNTP-Posting-Host: 12.158.183.115 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1057928727 21600 127.0.0.1 (11 Jul 2003 13:05:27 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 11 Jul 2003 13:05:27 GMT Xref: archiver1.google.com comp.lang.ada:40192 Date: 2003-07-11T13:05:27+00:00 List-Id: > Preben has pointed you to gdb and gvd, these are indeed nice but with Ada95 > you will probably very rarely have a need for a debugger, lot less than in C > for sure. I repeatedly read this kind of thing in this newsgroup, that once you move to Ada you'll "rarely need a debugger", you can "throw your debugger away", you'll "forget how to use a debugger", etc. In twenty years of professional programming (with Ada all along) I've found that a debugger is one of the most powerful tools in the Ada programmer's arsenal. Sure, if I write a small Ada program I can usually expect it to compile quickly and run right; but airplanes don't fly and missiles aren't launched by small programs. I read code all the time, but there's nothing as concrete as seeing how it's actually running in the computer, devoid of any programmer oversights or misunderstandings. It's frequently put forward that one can quickly debug their Ada program by putting in a few Put_Lines, and/or using pragmas Debug, Assert, and so on. Adding these of course all require a recompile to incorporate. There are many environments where putting an instrumented executble on the target platform requires making the change, compiling, and linking it; copying it onto a tape or disk; filling out some paperwork to authorize loading it on the test system; tracking down a CM person to bring the media into the lab and load it onto the machine; cycle the test system, which can require several minutes to bring down and then back up. versus... go to the lab and bring the sytem up in the debugger. You may discover that your Put_Lines may not be dumping all the items you need to debug the problem, but if it did, now you need to go add more in other places to further isolate the cause. Either way, that takes care of today's lab reservation! versus... Look at anything you please in the debugger. Based on my experience helping other developers debug their code, I've found a disconcertedly common trend when it comes to using debuggers. Very few know how to use one effectively--and this goes not just for Ada programmers, but programmers in general. The most common perception of a debugger I've seen held by programmers is that it's for single-stepping through code and setting breakpoints; and for the advanced user, examining variables. On several occasions when assisting other developers I've opened up the raw memory display window, or even (gasp!) the register or disassembly windows, and the look on the programmer's face is utter incomprehension (which may also be saying something about the state of software development education, but that's another rant :-). With the aid of a debugger I've tracked down numerous data alignment problems, stack overflows, tasking deadlocks, and just plain silly coding errors. Telling me that some Put_Lines and pragma Asserts are just as effective as gdb with a good front end (like gvd) I find laughable. I can hear someone muttering that a debugger is a crutch that a competent Ada programmer wouldn't find themselves needing. Hmm, substitute "strong typing" for "a debugger" and drop "Ada" and where have we heard that before? Considering a debugger to be superfluous to Ada programming deprives one of a very powerful tool. Unless all you're ever going to do is whip out quick little one-page Ada programs, learn how to _use_ a debugger. Counts, conditional expressions, memory dumps, display options, disassembly (know enough to basically follow what's going on), task and thread management, etc. A lot of effort has gone into making debuggers like gdb and gvd effective, take advantage of it! Marc A. Criley