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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Intervention needed? Date: Wed, 3 Apr 2019 20:23:36 +0300 Organization: Tidorum Ltd Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net zap1SitYJ77hgoAB9798KA8YNuZeo6k/bF9uo+7vAQ+sNmKVOu Cancel-Lock: sha1:g14KwW/IbS6pP31+8mIAUIJzK3M= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: Xref: reader01.eternal-september.org comp.lang.ada:56062 Date: 2019-04-03T20:23:36+03:00 List-Id: On 19-04-03 01:07 , Randy Brukardt wrote: > Does anyone spend much time in a debugger when writing Ada? I don't. I can't remember when I last used gdb or any other debugger, and in my ~30 years of Ada use I estimate that I have used a debugger on perhaps ten occasions. I have slightly more often used "monitor" programs to examine and alter memory and register contents when analysing problems in embedded programs, and those monitor programs can perhaps be considered crude debuggers. However, these cases involved the effects and meanings of HW control registers rather than ordinary program variables. A propos, the name "debugger" is IMO one of the unfortunate historical misnomers in the programming domain. It is a misnomer because a "debugger" like gdb should certainly not be our main tool for removing bugs from programs. Diving into the debugger as the first step of analysing a program failure is akin to starting a new project by diving into coding and skipping the design phase. Moreover, the activity of removing a bug from program, which should be the meaning of the term "debugging", should certainly not consist just of a gdb/debugger session. On the few occasions when I have used gdb or other debuggers, they have usually failed to help me understand the problem. The "interactive debugging" sessions have usually been frustrating. It is simply very hard to examine, understand and control the large, dynamic, complex beast that is the state of a program in execution, through the debugger's often imperfect understanding of the mapping between the source-level program and the machine state. Moreover, my programs are often real-time and multi-task and running gdb on such programs usually results in a quick malfunction because gdb is not in control of physical time. I find, like Dmitry, that tracing and logging functions, either built into the program and optionally activated, or inserted ad hoc to understand a specific bug, are more useful. Even if the problem is not found in the first attempt, but needs incremental addition or activation of more or other logs and traces, the process is much less frustrating than an interactive gdb session because there is much more control, much less noise due to irrelevant outputs from the program and the debugger, and no confusion between source level and machine level. However, I have not had access to any debugger with proper reverse-execution functions -- that is, a debugger that could show me not only what the program is doing "now", and what the variable values are "now", at the present breakpoint, but also what it was doing and what values the variables had in the recent or more distant past. If I had a debugger that could let me inspect the state of the program at any point in its execution, freely scanning and searching backwards as well as forwards in execution time, I might be tempted to try that debugger. (Another important programming misnomer is "comments", which should certainly not be random off-the-cuff commentary, but should be logical and well thought-out rationale, motivation, description, analysis, etc. But I digress.) -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .