Linear code sequence and jump

Abstract: A computer program is verified, unit by unit, by automatically instrumentating the code and generating a test driver program which executes all branches of an instrumented code unit. The code is instrumented by operating processors to standardize the code format and to insert executable tracer statements into each block of reformatted code between control statements. A pseudocode having only control statements and tables identifying valid linkages between blocks of code are generated by another processor for use by a verifier in selecting values of input variables and expected outputs for test cases which execute each block of code in the selected unit. Another processor generates the test driver program from the test cases and a software test specification identifying the test cases and expected results. The test driver program and instrumented code unit are compiled and linked to repeatively execute the instrumented code unit to implement all the test cases. Results of the test cases are printed out indicating the sequence of block linkages generated by each test case, the expected output values and the actual output values.

Abstract: Various kinds of research efforts have been performed on the basis that the presence of duplicate code has a negative impact on software evolution. A typical example is that, if we modify a code fragment that has been duplicated to other code fragments, it is necessary to consider whether the other code fragments have to be modified simultaneously or not. In this research, in order to investigate how much the presence of duplicate code is related to software evolution, we defined a new indicator, modification frequency. The indicator is a quantitative measure, and it allows us to objectively compare the maintainability of duplicate code and non-duplicate code. We conducted an experiment on 15 open source software systems, and the result showed that the presence of duplicate code does not have a negative impact on software evolution.

Abstract: One of the fundamental problems with the analysis of binary (executable) code is that of recognizing, in a machine-independent way, the target addresses of n-conditional branches implemented via a jump table. Without these addresses, the decoding of the machine instructions for a given procedure is incomplete, as well as any analysis on that procedure. We present a technique for recovering jump tables and their target addresses in a machine and compiler independent way. The technique is based on slicing and expression substitution. The assembly code of a procedure that contains an indexed jump is transformed into a normal form which allows us to determine where the jump table is located and what information it contains (e.g. offsets from the table or absolute addresses). The technique has been tested on SPARC and Pentium code generated by C, C++, Fortran and Pascal compilers. Our tests show that up to 90% more of the code in a text segment can be found by using this technique.

Abstract: A new approach for software debugging, verification and validation is disclosed. The present invention utilizes a knowledge-based reasoning approach to build a functional model of the software code for identifying and isolating failures in the software code. The knowledge-based reasoning approach of the present invention uses the software design, which is preferably based upon a flow chart or block diagram representation of the software functionality, to build the functional model. The software block diagram contributes to the functional model by defining the inputs and outputs of the various blocks of code, as well as defining data interconnections between the various blocks of code. In accordance with a method of the present invention, test points are strategically inserted throughout the code, and each test point is associated with a corresponding block of code. Expected values of the test points for an expected proper-operation execution of the computer program are generated. The computer program is then executed on a computer, and the actual values of the test points from the program execution are compared with the expected values of the test points. Failed test points which do not agree with corresponding expected values are determined. The functional model, which includes information functionally relating the various test points to one another, is then used to isolate the failed test points to one or more sources of failure in the code.