CA2030227C

CA2030227C - Assembly language programming potential error detection scheme sensing apparent inconsistency with a previous operation

Info

Publication number: CA2030227C
Application number: CA002030227A
Authority: CA
Inventors: Robert G. Hansen
Original assignee: Bull HN Information Systems Inc
Current assignee: Bull HN Information Systems Inc
Priority date: 1989-11-29
Filing date: 1990-11-19
Publication date: 1994-07-05
Anticipated expiration: 2010-11-19
Also published as: EP0430182A2; JPH0748182B2; AU6679990A; EP0430182B1; DE69026208D1; US5132972A; EP0430182A3; CA2030227A1; JPH03188535A; DE69026208T2; AU629707B2

Abstract

ABSTRACT OF THE DISCLOSURE

A computer aided software engineering tool is disclosed which is particularly well adapted to identity potential Assembly language source code errors resulting from the analysis of statements which do not contain incorrect syntax, limits, operand specification, etc.; i.e., do not contain any errors of the type which can be generally categorized as incorrect usage. This objective is achieved by providing a debugging program which has a complete awareness of the specific machine architecture, such as the function of each instruction and the register(s), flags, etc. it affects. By essentially stepping through the Assembly language statements in much the same manner as a computer would while executing the corresponding instructions, the debugging program is able, through such simulation, to identify, in the Assembly language program under study, specific potential inconsistencies with previous operations which the debugging program has been coded to detect and, upon such detection, to issue an appropriate warning message. The programmer may then examine the flagged Assembly language code to determine if a genuine error exists.

Description

2 ~3 ~ 2 2 7 ASSEMBLY LANGUAGE PROGRAMMING POTENTIAL ERROR DETECTION
SCHEME SENSING APPAR~NT INCONSISTENCY WITH A PREVIOUS
OPERATION

Fleld of the Inventlon Thls invention relates to the art of computer programmlng and, more particularly, to an Assembly language -debugglng software englneerlng tool partlcularly adapted to detect loglcal or contextual ~nconsistencles in statements whlch are .:
syntactlcally valid; l.e., ln statements whlch do not contain any errors of the type whlch can be generally categorlzed as lncorrect usage.

:
Backqround of the Inventlon As those skllled ln tne art well understand, computer programmlng ls rarely performed dlrectly ln machlne language. -~- -Instead, programrning is usually carried out ln hlgher language ., . " ~
form such as C, BASIC, FORTRAN, COBOL, PASCAL, etc. In the case of BASIC, a resultant "source" program can then be executed employing a machlne resldent ,::

.-:

interpreter program which reads the lndlvldual source code programming statements and converts them to machine -instructions (appropriate for the hardware being used) on a .-statemen~ by state~ent basis. This is a relatively slow process, however, and more efficient and very much ~aster ; ~
execution of a BASIC program can be obtained by first~--processing it through a compiler program specifically created to prepare executable or "object" code in an optimum sequence for a given type of hardware. Compilation is routinely carried out (in fact, is required) even during the programming and program proving tasks for many of the high level programs such as C. ~ - `
Some programmers prefer to work in a less high level, more machine specific, language designated "Assembly" which is readily reduced to machine level instructions with an "Assembler" program in an operation similar to, but much more straightforward than, compilation. The resultant object code is very efficient. However, because Assembly is a low level language, it is notoriously easy, during the coding process, to introduce subtle programming errors (or "bugs") which the Assembler will not catch and which may b~
particularly elusive to identify and remedy during the program proof (or "debugging") process.
one class of errors of this elusive sort are those in which an Assembly language statemsnt is entirely legal in -~
that syntax, limits, specification of operands, etc. are all properly incorporated, but the correctly configured ~ -2 ~ ~

'~ ', ` '` `'`~ `.

: ' ~ '`~ ' ' ` ' ` ` : . ' ' .
' ` ~ ' . ~ '` . ` ` :

~J ~ ~ ~ f;J~ 2 ~
statement is nonetheless apparently logically inconsistent with a previous operation. It is to the early detection of elusive programming errors of this class that the present invention is directed.
~'~

o~ec~s of thç~ y~ t It is therefore a broad object of this invention to provide an improved debugging tool for analyzing the source of computer programs written in Assembly language.
It is a more specific object of this invention to provide a debugging program which is capable of identifying, in Assembly language source code, elusive programming errors of a type in which statements are correct if considered by themselves, but are illogical in the context of previous operations.

Summary of the Invention Briefly, these and other objects of the invention are achieved by providing a debugging program which has a complete awareness of the specific machine architecture, such as the function of each instruction and the register(s), flags, etc. it affects. By essentially stepping through the Assembly language statements in much the same manner as a computer would while executing the corresponding instructions, the debugging program is able, through such examination, to identify, in the Assembly language program under study, specific potential ; ~' .~ - ' ' ' ' `'' - ~
,'` ' ~: , :,: - ~: . - ,, :

- 2 ~ 3 0 2 2 7 72434-111 .-lnconslstencles with prevlous operations whlch the debugglng program has been coded to detect and, upon such detectlon, to lssue an appropriate warning message. The programmer may then examine the flagged Assembly language code to determine if a genuine error exlsts. ~.
In accordance wlth the present inventlon there is .
provided a computer-implemented method of detecting one class of posslble errors ln a computer program comprlslng a serles of source code statements, characterlzed by the computer~executed ---steps of~
A) establlshlng a software representation of the architecture .
of the computer in which the complied form of said computer program will be executed~
~) obtaining one of sald source code statements; .
C) analyzlng the operation directed by sald statement and ;~
applying said analysis to said architecture to determine whether the results of executlng said operation would be inconslstent wlth the results of the executlon of ~ preceding operation, and if said t~
analysis determines~
i) an inconsistency, generating a warning message; .-ii) no inconsistency, going to step D; and D) obtaining the next source code statement of sald serles ;`~--`
and then returning to step C. -~ .

DescriPtion of the Drawin~
The subject matter of the invention is partlcularly pointed out and dlstlnctly claimed in the concluding portion of "

: ~ 4 , . .,. ~ -: .. , , . -2~3~27 ~ -... . .

the specification. The lnvention, however, ~oth as to organizatlon and method of operation, may best be understood by ~:
reference to the followlng description taken in con~unction with -~
the sub~oined claims and the accompanylng drawing of which~
FIG. 1 is a high level flow chart illustrating the general ;~
sequence of a debugging program in whlch the present invention may be incorporated; and ;.
FIG. 2, constitutlng FIG 2A and FIG. 2B taken together, ls a more detailed flow chart discloslng the structure of the debugglng ` -~-module in which the present lnvention is incorporated.

Detailed Descri~tlon of the Invention As previously discussed, one class of particularly difflcult to find program bugs encountered are those in whlch an Assembly language source code statement ls entlrely correct insofar as syntax, limits, specification of ~

4a : ~:

' ~

~.~ . . . ~ : ,., . : : . . -~:
r5~ r;~
operands, etc. are concerned, but the correctly configured statement is nonetheless logically inconsistent with a previous operation. Such inconsistencies may include the following:

1. The indicators set by a preceding compare -instruction were not tested or stored, and the current ; ;
instruction will now cause these indicators to be changed; ~ ~ `
'"'~'- ''-, 2. The current instruction will load (and thus destroy) a register which was previously modified, but which was never stored or used as a modifier.

3. The upper or lower half o~ a register has been force-cleared by some prior operation; however, this half register is now being used either as an operand or as a modifier. Force-clearing may be the result of a shift, load or "AND" operation.

4. A conditional transfer i5 being attempted based upon an indicator which was not affected by a previous operation.
.. . . .. . .

; 5. A register whose contents are known to be destroyed by a system service function is now being called upon .
,.: ' ':, ;~''~

:

. ~

for use as a modifier without being reloaded ~aSf~e~r~J
invoking the ~unction 6. A symbol which previously appeared in the context ~f a csrtain type of address modification is now being called upon for u~e in a different type o~ context.

7. A subroutine which has previously been observed to use a given index register for linkage is now being called using a different index register.

Attention is first directed to FIG. 1 which is a high level flow chart illustrating the general sequence of a debugging program of the present class. As a first step in setting up the debugging, certain essential aspects of the ~ , architecture of the machine for which object code is to be generated is represented in software in a manner well known to those skilled in the art. Briefly, merely as an elementary example, consider a case in which a certain address is developed (in the machine for which ob~ect code is to be generated) by combining information from two sources. The fact of that characteristic is encoded into the debugging program along with code for tracking what would happen to the information sources and to the address .: , as the Assembly language statements are examined one at a time. Now, if one of the sources can be determined to have been destroyed by a previous operation and never reloaded .
., . ~ .
: ' ~''`' ~"~

with meaningful information prior to its use in developing an address, something is probably wrong notwithstanding completely correct syntax, etc. of all the relevant source code.
For an example of the manner in which the relevant architectural characteristics of hardware employing the GCOS
8 opexating system may be represented, one may refer to pages 2 - 54 of the aforementioned Microfiche Appendix.
Various tests can be conducted on a step by step basis as an Assembly language source code program under test is examined and analyzed, and failure of any of the tests can result in the issuance of an appropriate error message for the benefit of the progra~mer. The present invention, however, relates to a series of related tests, directed to the above-enumerated logical inconsistencies, in a stand alone module of the debugging program and is represented in FIG. 1 by the inquiry block: "INCONSIS~ENT WITH A PREVIOUS
OPERATION?". Following completion of the subject battery of tests, any other tests remaining in the debugging program may be run to conclude the testing of the source code program or program module.
Attention is now directed to FIG. 2 (i.e., FIGs. 2A and 2B taken together) which is a detailed flow chart disclosing the operation of the subject Assembly language source code test module in which inconsistency of a given statement with a prior operation called for by the source code program or program module under test is examined, notwithstanding its ~ ' ": ~

. . f~ ^f ~ f'~
otherwise correct attributes. In the following discussion, the use of Assembly~ language source code is assumed such that a statement is very closely related to a single machine language instruction. -Thus, starting from the beginning of the source code program or program module under examination, the next statement is called for analysis. If it is an end-of-file statement, an exit is made to the next series of tests; if not, a determination is made as to whether it is a mere comment ~which need not be analyzed). If it is a comment, the next statement is called; if not, the analysis proceeds on the merits.
The first inquiry is whether an instruction will change an indicator or flag. If so, a determination is made as to ;
whether a preceding instruction also set indicators and, if so, whether any intervening use was made of the indicator states. I~ a preceding instruction set indicators, but no intervening use was made of them, and now the indicators are ~-a~ain being set, a logical inconsistency may be present, and ~ - -a specific error message to that effect is issued to alert `
the programmer to the potential problem. If the statement under examination does not involve setting indicators, or if it does, but a previous indicator setting was, in fact, legitimately used, then the next test in the module may be undertaken.
Next, an inquiry is made to determine if the statement will cause a given register to be loaded or modified. If 8 ~ ` ;

!
7 ~ '' ' 7 - ) ` ` ' ~ " ' ' ~ ' ~ r `, ' ' `:`
'. ~'"

7 -`
so, a determination is made as to whether a preceding instruction also loaded or modified the same register and, if so, whether any intervening use was made of the register contents. If a preceding instruction loaded or modified the register, but no intervening use was made of its contents, and now the register is again being loaded or modified, a logical inconsistency may be present, and a specific warning message to that effect is issued to alert the programmer to the potential problem. If the statement under examination does not involve loading or modifying a register, or if it does, but the register contents were, in fact, legitimately used, then the next test in the module may be undertaken.
Next, if the statement under investigation uses a direct operand or modifier which constitutes a half-register, a determination is made as to the validity of its use. For example, if a prior operation resulted in force clearing the specified half-register, then it probably was the programmer's intention to use the other register-half, and an appropriate warning message is issued. Force clearing may be the result of a shift, direct operand load or logical AND operation.
Next, the statement under test is examined to determine if it calls for a conditional transfer. If not, the next test in the suite is performed. If so, a determination is made as to whether the indicator being tested was affected by a previous compare or load instruction. If the indicator was not affected, it is likely that an incorrect test is 9 ; `.. ''.

' ' ~' ' ``'``' .~ '. '`'' ``""'-~

~ 32~ o being performed, and an appropriate warning message is issued.
A determination is now made as to whether or not a sys~em service function was previously invoked which destroyed the contents of a register which is now being called upon to be used as a modifier or operand without being reloaded after invoking the system service function.
If so, the contents of the re~ister are invalid for the request, the usage of the register is incorrect and a warning message is issued.
Next, a detennination is made as to whether or not a symbol has been used in the address field or any modifler field and, if so whether the symbol has previously appeared in a conflicting context. If the symbol usage is inappropriate, a warning message is generated.
If the symbol usage is appropriate, a determination is made as to whether a subroutine is being called. If not, the statement under examination can be considered not inconsistent with a previous operation, and the next statement can be taken up for analysis. However, if a subroutine is being called, further analysis is necessary.
If the subroutine was not called previously, the statement under examination can now be considered not inconsistent with a previous operation, and the next statement can be taken up for analysis. But, if the subroutine was called previously, it is necessary to determine if the same linkage ,.-;.-..~. ''"''-'' 1 0 , , . ~

~;
.` ~

2a30227 : - ~
7 2434~
reglster was used; lf so, the next statement may be called, bUt, if not, a warnlng message is issued.
Accordlng to the embodlment of the sub~ect inventlon shown in FIG. 2, ln each case of the issuance of a warnlng message, the ~ebugging program continues right on through the entlre Assembly language source code program or program module under examlnatlon, the next statement can be called up for : --analysls as lndlcated ln FIG. 2. Thus, the entlre group of warnlng messages can be revlewed as a group, recognlzlng that there may be lnterrelatlonships among the bugs or posslble bugs, ' .;
::: ~, ., :i for revlslon of the source code as may be approprlate. -~

Alternatlvely, those skllled ln the art wlll understand that the :~
. . . ~
debugging program could be readlly revlsed such that lts executlon can be made to termlnate after each warnlng message ls lssued such that the "earllest remalnlng" bug or potentlal bug of the sort detectable by the sub~ect program can be addressed by the programmer. E~perlence has shownl however, that the mode of operatlon shown ln FIG. 2 ls preferable. -~
.
Thusl whlle the prlnclples of the lnventlon have now .
been made clear ln an lllustratlve embodlmentl there wlll be lmmediately obvlous to those skllled ln the art many modiflcatlons ~ -of program structure used ln the practlce of the lnventlon whlch are partlcularly adapted for specific envlronments and operatlng ~'~''``'`'.''~r~''~`~
~ ~, ' ` .
requlrements wlthout departlng from those prlnclples.

. - . ,., ~

' . ' ' . `' `' ~' ' ` '', ' '~ '~`

11 '`'"`" ~ ~ '

Claims

1. A computer-implemented method of detecting one class of possible errors in a computer program comprising a series of source code statements, characterized by the computer-executed steps of:
A) establishing a software representation of the architecture of the computer in which the complied form of said computer program will be executed;
B) obtaining one of said source code statements;
C) analyzing the operation directed by said statement and applying said analysis to said architecture to determine whether the results of executing said operation would be inconsistent with the results of the execution of a preceding operation, and if said analysis determines:
i) an inconsistency, generating a warning message;
ii) no inconsistency, going to step D; and D) obtaining the next source code statement of said series and then returning to step C.

2. The computer aided software engineering process of Claim 1 which includes, within step C), the sub step of determining if an indicator set by a preceding compare instruction was not tested or stored and the instruction whose execution is being simulated will cause the indicator to be changed; a positive determination invoking step C)i), and a negative determination invoking step C)ii).

3. The computer aided software engineering process of Claim 1 which includes, within step C), the sub step of determining if the instruction whose execution is being simulated will load a register which was previously modified, but never stored or used as a modifier; a positive determination invoking step C)i), and a negative determination invoking step C)ii).

4. The computer aided software engineering process of Claim 1 which includes, within step C), the sub step of determining if the instruction whose execution is being simulated will employ as an operand or modifier a register segment which was last affected by force clearing; a positive determination invoking step C)i), and a negative determination invoking step C)ii).

5. The computer aided software engineering process of Claim 1 which includes, within step C), the sub step of determining if the instruction whose execution is being simulated will attempt a conditional transfer based upon an indicator which was not affected by a previous operation; a positive determination invoking step C)i), and a negative determination invoking step C)ii).

6. The computer aided software engineering process of Claim 1 which includes, within step C), the sub step of determining if the instruction whose execution is being simulated will attempt to use a register as a modifier which has previously been destroyed by a system service function and has not been reloaded; a positive determination invoking step C)i), and a negative determination invoking step C)ii).

7. The computer aided software engineering process of Claim 1 which includes, within step C), the sub step of determining if the instruction whose execution is being simulated will attempt to use a symbol in a given context of address modification which previously appeared in a different context; a positive determination invoking step C)i), and a negative determination invoking step C)ii).

8. The computer aided software engineering process of Claim 1 which includes, within step C), the sub step of determining if the instruction whose execution is being simulated will call a subroutine using a given index register for linkage, which subroutine utilizes a different index register; a positive determination invoking step C)i), and a negative determination invoking step C)ii).

9. The computer aided software engineering process of Claim 1 which further includes the step of exiting following performance of step C)i).

10. The computer-implemented method of claim 1, further characterized by:

in step C)i), after the generation of said warning message, going to step D.