Re: Intervention needed?

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

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
       .      @       .