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.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Intervention needed? Date: Thu, 4 Apr 2019 11:37:18 +0300 Organization: Tidorum Ltd Message-ID: References: <1e27ce78-217d-4adc-8380-30f6d4fc5fdc@googlegroups.com> <878swq2q1m.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net MfR8OCr3ESrPb2zy7yf7Fw8i/8SDORRnOYB5zZWM2cJACjIKkn Cancel-Lock: sha1:m7Ls5v62DVEQSarFE/0RIenbkZo= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <878swq2q1m.fsf@nightsong.com> Xref: reader01.eternal-september.org comp.lang.ada:56074 Date: 2019-04-04T11:37:18+03:00 List-Id: On 19-04-04 10:22 , Paul Rubin wrote: > Maciej Sobczak writes: >> The major use for debuggers that I see is in integration testing, >> where test procedures expect particular values in particular variables >> (or even exact memory locations) in particular circumstances. > > You should really automate tests like that. As gdb can be scripted, the tests that Maciej describes can probably be automated, albeit with considerable effort, especially if the scripts should be robust to evolution of the SW under test (changing the line numbers of the required breakpoints, etc.) In my domain (on-board satellite SW) the current practice is to fuse unit tests with integration tests, with a relatively smooth progression from operation-level tests, through module-level tests, to subsystem-level tests, with mostly the same techniques and tools at all levels: provide inputs, check outputs and calls (with stubs), measure coverage. Debuggers are not used. It is true that current unit-testing tools do not easily let one see and check internal states and values, in the way Maciej describes that gdb is used. However, I don't think that gdb or other current debuggers are ideal tools for automated checking of internal states. I have seen increasing activity (conferences and such) on "run-time verification", and I would expect better tools to emerge from those activities. > I find debuggers very useful for understanding how an unfamiliar piece > of poorly documented code works. What are the conditions when this > function XYZ is called, and how does the program get there? Load the > program into debugger, set breakpoint at XYZ, and run. You see only one _instance_ of an execution. I usually prefer to have a static analysis give me call-graph which represents _all_ possible executions and gives me a general understanding of the program. But I agree that instances can also be useful to check that one's general understanding is correct. Both points (Maciej's and Paul's) support my opinion that "debugger" is the wrong word for these tools. Their main use is to _view_ or _inspect_ the execution states of a program, not to "remove bugs". > What happens in case of this other input? Set breakpoint earlier, > run with other input and single step to understand flow of the > program, etc. That is exactly the form of trial-and-error "debugging" that I abhor, because it usually provides a mass of instances from which I find it hard to extract any general understanding. Moreover, I find it less troublesome to modify the logging/tracing set-up before a re-run. The recompilation time is insignificant compared to the thinking time. > There will always be logic errors in programs too. Sure you can debug > them with print statements and recompiles, but debuggers and breakpoints > basically give you a way to insert the print statements interactively > and dynamically while the program is running. Except for real-time, concurrent programs... and with quite some problems to "print" complex data structures in readable form. I do think that we should have ways, and better ways, to inspect and check program executions at run time. One could say that most of the effort, so far, in programming tool development has been on means to let programmers define what the program _should_ do, with increasingly expressive and powerful programming languages and compilers or other means to facilitate the execution of the programs so defined. But work on tools that let us see and understand what the program _actually_ does has lagged behind. There has been work on algorithm visualization, including work to visualize task switches and inter-task communications (scheduling traces), and much work on visualization of program outputs, but not much work on presenting program executions in understandable yet precise ways. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .