NASA CONTRACTOR REPORT h c14 m v I PL U 4 r/) 4 z A SURVEY OF CURRENT DEBUGGING CONCEPTS by WaZZace Kocher Prepared by WOLF RESEARCH AND DEVELOPMENTCORPORATION Bladensburg, Md. for Goddard Space Flight Center NATIONALAERONAUTICS AND SPACE ADMINISTRATION WASHINGTON, D. C. AUGUST 1969 TECH LIBRARY KAFB, Nhl 0060538 NASA CR-I397 A SURVEY OF CURRENT DEBUGGING CONCEPTS By Wallace Kocher Distribution of this report is provided in the interestof informationexchange. Responsibility for thecontents resides in the author or organization that prepared it. Prepared under Contract No. NAS 5-9756-99 by WOLF RESEARCH AND DEVELOPMENT CORPORATION Bladensburg, Md. for Goddard Space Flight Center NATIONAL AERONAUTICS AND SPACE ADMINISTRATION For sale by the Clearinghouse for Federal Scientific and Technical Information Springfield, Virginia 22151 - CFSTl price $3.00 TABLE OF CONTENTS Section Page I INTRODUCTION - - - - - - - - - - 1-1 1-1 Need for DebuggingDevelopment - 1-1 1-2 Scope of ThisReport - - - - - - 1-1 1-3 DebuggingAspects, Definitions - 1-2 1-4 Categories of Programming Errors 1-3 1-5 Phases of Debugging - - - - 1-4 1-6 Error Diagnostic Procedures 1-4 ._ I1 IMP-F PROGFAM DEBUSGING - - 2-1 2-1 Description of the Programs 2-1 2- 2 Programmer Comments - - - - 2-2 2-3 InterviewGuidelines - - - - 2-3 I11 CURRENT DEBUGGING CONCEPTS - 3-1 3- 1 CurrentConcepts - - - - - - 3- 1 3-2Preliminary Testing - .- 3-1 3-3 Checkingthe Flow Chart 3-1 I 3-4 Linkingthe Flow Chart to the Coding 3-3 3-5Concluding Steps 02 PreliminaryTesting 3-3 3-6 Assemblingand Coqillng L""""_ 3-4 3-7 AssemblerAids - - - - - - - - - - - - - 3-4 3-8Compiler Aids - - - - - - - - - - - - - 3-5 iii .... ". - ._._ TABLE OF CONTENTS (Continued) Section Page 3-9Macro-Instructions - - - - - - - - - - - - - - 3-7 3-10Debugging Macros - - - - - - - - - - - 3-7 3-11Advantages ofDebugging Macros - - - - 3-8 3-12 The SDC-SFARE DebuggingPackage - - - - 3-9 3-13Inserting' Diagnostic Instructions - - - - - - 3-11 3-14 B~~~ - - - - - - - - - - - - - - - - - - - - 3-12 3-15Postmortem Dumps - - - - - - - - - - - 3-12 3-16Snapshot Dumps - - - - - - - - - - - - 3-13 3-17Inconveniences of PresentTechniques - 3-13 3-18Efforts to Improve Dumping Techniques - 3-14 3-19 The ALCOR Illinois 7090./7094 Post Mortem Dump - - - - - - - - - - - 3-15 3-20 The UNIVAC 1108Executive Systems - - - 3-18 3-21 The Snapshot Dump - - - - - - - 3-19 3-22 The Postmortem Dump - - - - - - 3-20 3-23 Traces - - - - - - - - - - - - - - - - - - - - 3-20 3-24Possibilities for Limitingtke Trace - 3-21 3-25Trapping - - - - - - - - - - - - - - - 3-22 3-26 Static Trace - - - - - - - - - - - - - 3-22 3-27Improved Approach toTracing - - - - - 3-23 3-28 The SEFLO TracingTechnique - - - - - - 3-25 3-29Dynamic Debugging - - - - - - - - - - - - - - 3-25 3-30 FORTRAN DebuggingLanguages - - - - - - 3-27 iv TABLE OF CONTENTS (Continued) Section 3-32 DIAGNOSE, Another FORTRAN DebuggingLanguage - - - - - - - 3-28 3-33 BUGTRAN, Another FORTRAN DebuggingLanguage - - - - - - - 3-30 3-34 TESTRAN, for IBM System/360 - - - - - - 3-32 3-35 Introductionto TESTRAN - - - - 3-32 3-36 Procedure - - - - - - - - - - - 3-33 3-37 The "Rip Stopper" Method - - - - - - - 3-35 3-38 The WATCHR I11 System - - - - - - - - - 3-36 3-39 TIDY and EDIT for FORTRAN - - - - - - - - - - 3-40 3-40 The TIDY program - - - - - - - - - - - 3-40 3-41 The EDIT Program - - - - - - - - - - - 3-42 3-42 AutomaticFlowcharting - - - - - - - - - - - - 3-43 3-43 The AUTOFLOW System - - - - - - - - - - 3-43 3-44 Testing - - - - - - - - - - - - - - - - - - 3-44 3-45 Purposes - - - - - - - - - - - - - - - 3-44 3-46 Problems - - - - - - - - - - - - 3-45, 3-49 Satellite Test Data - - - - - - - - - - 3-46 TABLE OF CONTENTS (Continued) Page 4-1 On-Line Debugging Techniques - - - - - - - - - - - - 4-1 4-2 Criteria for an On-Line Debugging System - - - 4-2 4-3 The Programmer-Controlled Breakpoint - - - - - 4-2 4-4Assembler-Language Program Debugging: The DDT System - - - - - - - - - - - - - - - 4-3 4-5 Higher-Level Language Debugging - - - - - - - 4-7 4-6 The LISP System - - - - - - - - - - - - 4- 7 4-7 The QUIKTRAN System - - - - - - - - - - 4-9 4-8 The Incremental Compiler - - - - - - - - 4-9 vi SECTION I INTRODUCTION 1-1. NEED FOR DEBUGGING DEVELOPMENT Debugging is a general term that refers to the loca- tion and correction of errors that occur in computer pro- grams. The debuggingactivity may consume considerable portions of the total time required for the complete pro- gram development.However, the importance of thisarea of programdevelopment has often been minimized. The purpose of this report is toplace some emphasison this important area and to present some ofthe current debugging concepts which may beconsidered for implementation. Computers are continually becoming faster andmore complex,and applications becoming more extensive, more intricate, and more time-critical. Thus,the need for a greatereffort in the area of debugging is obvious. Two of the major €actors which make program errors both harder to find and harder to tolerate are time-constrained program- ming andclosed-loop applications. These are particularly applicable to many of the space-related programs. 1-2. SCOPE OF THIS REPORT The projectthat has famished impetus to this report is the IMP-F (InterplanetaryMonitoring Platform). Becausethe IMP-F computer program complex will form the basis for future IMP efforts, it was necessary to document the present version as fully as possible in order to reduce the lead time andcost of developing the follow-on IMP 1-1 complexes. One importantarea (and the subject of this paper) is debugging.This report includes, in addition to thedocumentation of the IMP-F debuggingeffort, a survey of currentdebugging concepts which may beconsidered for implementationin future programs. 1-3. DEBUGGING ASPECTS, DEFINITIONS For thepurposes of thisreport, debugging will be considered to includelogical and clericalerrors but not machinemalfunctions. To be more specific,debugging includesprevention, detection, diagnosis, recovery, and remedy ofprogram errors. It is anon-going process that lasts for theentire lifetime of theprogram. The following 1 definitionsclarify the above mentioned aspects: a. Prevention - protectiveaction taken against theoccurrence of errorsor omissions. b. Detection - determination of theoccurrence of anerror or ofan omission at the earliest pointpossible so as to limit theconsequences. C. Diagnosis - analysisof the error that was detected. d. Recovery - provision for ameans of bypassing anerror coniiition, especially one ofan intermittent nature, with a minimum loss of timeand effort. 1-2 e. Remedy - rapidremedial action employed to preventfurther occurrences of the same or similar errors andomissions. 1-4. CATEGORIES OF PROGRAMMING ERRORS Programming errors fall into two basiccategories - logical and clerical. Logicalerrors are those which involve problem analysis.Although they occur less frequently than 'clerical errors they are usually more serious andmore difficult to detect.Since they often occur early in theprogram writing process,they have a tendency to beoverlooked. Frequently they are a result of amisunderstanding of theproblem and requirements.Often, in very complex programs, errors result from failure to cover all possible alternatives that may arise, fromimprope-r identificationof storage areas, etc. Clericalerrors are those errors which involve the inputdeck or otherinput media; these errors are sometimes referred to asphysical errors, and errors made in writing symbolicinstructions. Numbers may betransposed, cards may beomitted or mispunched,a symbolic namemay be spelled more thanone way, to mentiona few types of these errors.Frequently these errors are the result of careless- ness. Onecommon source of sucherrors may beavoided by keepingprogram listings and decks up to date; old versions should be destroyed or at least marked. ._ . .. "" ~ __""""_""____"..__I __" . ~ T"" "" - 1-5. PHASES OF DEBUGGING The debuggingprocess is generallythought of as 2 consisting of several phases: a. Desk checking. b. Assembled or compiledprogram checking. C. Program-testingusing test data. d. Error diagnostic procedures. e. Runningof program using actual data. 1-6. ERROR DIAGNOSTIC PROCEDURES Inthis report, emphasis is placed on thephase dealingwith error diagnostic procedures. A number of programsand programming techniques are available for diagnosticpurposes. Their underlying principle is to provide information about a particular portion or portions of theprogram as control passes through the specified instructions. The amount arid location of theinformation will varydepending on thenature of theerror. Proposals havebeen EaGe fordeveloping software that will allow debugging to beconducted using the same languageas the sourceprogram; however, few of thesehave been implemented. Few if anycomputer systems or majorlanguages today.pro- videcomprehensive symbolic debugging software packages. 1-4 SECTION I1 IMP-F PROGRAM DEBUGGING 2-1. DESCRIPTION OF THE PROGRAMS Informationconcerning the debugging of time- correction anddecommutation programs for the IMP-F space- craft vas collected through a series of interviewswith programmersand project managers associated with the pro- ject. The IMP-F time-correctionand decommutation programs were written in FORTRAN andthe UNIVAC 1108 assemblerlangu- age, SLEUTH 11. a. The time-correctionprograms perform two basic operations: 1. Correctrange time data byremoving discontinuities and filling in missing timedata. 2. Establishfairly precise correlation