US 5,754,861 AGrant
Dynamic Program Input/Output Determination
Issue Date:1998-05-19
•30 Claims
•9 Drawing Sheets
Abstract
A computer program's run-time inputs and outputs are dynamically, non-intrusively, and executable-independently determined by wrapping a "Wrapper" around the computer program. The "Wrapper" turns on system traces (102), executes the computer program (104), and turns off the system traces (106). It then reads and evaluates the traces (108), identifying process and file information corresponding to the recent execution of the computer program (104). This process and file information is collected and written to a Run History data base (310).
Metadata
Assignee
- Motorola, Inc.
Inventor
- Anita Kumar
Application Information
Application Number:US 5157307
Filing Date:1995-08-16
Priority Date:1995-08-16
Art Unit:274
Classifications
IPC:
G06F 1134
Field of Search:
395704
Patent Drawings (9 sheets)
Description
Cross Reference to Related Application
This application is related to our copending patent application entitled FILE CONFIGURATION AUDIT SYSTEM, filed of even date herewith and assigned to the assignee hereof.
Field of the Invention
The present invention generally relates to production control software, and more specifically to identifying and recording computer program inputs and outputs.
Background of the Invention
A deterministic program's run time course is determined by its inputs: its environment variables, command line parameters, and input files. Identification and recording of these input stimuli along with the corresponding output responses in a run history file at run time can be useful when determining which programs have been run with which inputs.
The traditional solution to this problem required that the run history information be entered manually. The 1970 Decennial Census required an entire branch of clerks to keep track of the Census input and output files. This approach has all of the disadvantages of manual operations: it is slow, labor intensive, and inaccurate.
Another alternative is to incorporate code in each program that automatically records the information for each run of each program. This works very well in situations where source code is available to be modified. Unfortunately, it does not work in situations where source code is unavailable. Source code is rarely available for programs licensed from third parties. This approach also requires remodification and recompilation whenever changes are made to the base code. This too can cause significant problems.
A somewhat similar approach is the use of custom bill-of-materials generators. Each custom bill-of-materials generator relies on knowledge about its associated program to function. This again requires at least read access to the source code of the associated program and has the disadvantage of potentially being out of sync with its associated program due to a bug in the update of the program.
There is a significant need for an automated system to determine and record in a run history data base a program's inputs and outputs. This automated system needs to operate without knowledge of the internals of the program, allowing its use with 3rd party software.
Summary of the Invention
In accordance with the invention, a computer program's run-time inputs and outputs are dynamically, non-intrusively, and executable-independently determined by wrapping a "Wrapper" around the computer program. The "Wrapper" turns on system traces, executes the computer program, and turns off the system traces. It then reads and evaluates the traces, identifying process and file information corresponding to the recent execution of the computer program. This process and file information is collected and written to a Run History data base.
These and other features, and advantages, will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings. It is important to point out that there may be other embodiments of the present invention which are not specifically illustrated.
Brief Description of the Drawings
FIG. 1 is a block diagram illustrating the problems addressed by this invention;
FIGS. 2-5 are flowcharts showing the operation of one implementation of the Validity Checker, in accordance with one embodiment of the present invention;
FIG. 6 is a block diagram showing the components in a more general implementation of the Validity Checker, in accordance with one embodiment of the present invention;
FIG. 7 is a flowchart showing the operation of the preferred embodiment shown in FIG. 6;
FIGS. 8-12 are flowcharts showing the operation of a UNIX implementation of the Automatic Run History Generator, in accordance with the present invention;
FIG. 13 is a block diagram of a general purpose computer such as is used to implement this invention.
Detailed Description of a Preferred Embodiment
At one time, complex integrated circuits designs, such as those for microprocessors, were developed in a serial fashion: one model of the chip evolved over time. But in order to achieve cycle time objectives in today's competitive environment, different models of a chip must co-exist and evolve concurrently, until the various models can be integrated and tested.
In addition to the ability to build totally separate designs in parallel, it is also extremely helpful to be able to have multiple people working on the same design in parallel. One example of this is the instance where one designer finishes a version of his portion of an Integrated Circuit ("IC") and sends the version out for testing. He then makes modifications to that version. At that point, the version that the designer is working on is different from the version being used by the tester.
The coordination of these various versions can become very complex. Yet it is essential to validate that all of the appropriate tests have been applied to the appropriate versions of a design before the design is used in the production of the Integrated Circuit (IC).
FIG. 1 is a block diagram illustrating the problems addressed by this invention. Two circuit schematics are shown: V1 60, and V2 62. Each of these circuit schematics 60, 62 must be run through a set of tests 64, 66 to prove their correctness. From each of the schematics 60, 62, multiple circuit layouts are created 70, 72, 74, 76, 78. Schematic V1 60 is first laid out 70 as layout V1#1 80, then laid out 72 as layout V1#2 82. Likewise circuit schematic V2 62 is laid out first 74 as layout V2#1 84, next 76 as layout V2#2 86, and finally laid out 78 as V2#3 88. Each of the layouts 80, 82, 84, 86, 88, must also be run through a set series of tests 90, 92, 94, 96, 98.
Before a given layout can be used in the production of Integrated Circuits (IC), it must be shown that the layout is correct. This requires that:
1) The schematic be shown correct,
2) The layout be shown correct, and
3) The schematic be shown to match the layout.
For example, in order to utilize layout V1#1 80 in FIG. 1 in the construction an IC, layout V1#1 80 should be verified by:
1) showing that schematic V1 60 has been successfully run against all of the tests in schematic test suite 64,
2) showing that layout V1#1 80 has been successfully run against all of the tests in layout test suite 90, and
3) showing that schematic V1 60 is electrically equivalent to layout V1#1 80.
One problem that occurs with great regularity in this type of environment is where not all tests will be rerun after a change is made. For example, suppose that layout V1#1 80 is made from schematic V1 60. Tests are then begun 90 on layout V1#1 80. Meanwhile, schematic V1 60 is slightly modified, resulting in schematic V2 62. Schematic V2 62 passes all of its tests 66, as does 90 layout V1#1 80. But note that layout V1#1 80 does not match schematic V2 62. At this point, we cannot certify that layout V1#1 80 is correct and usable, since it doesn't match a tested schematic (V2 62).
The design of a single Integrated Circuit (IC) chip these days requires many more files than the two schematic files and five layout files shown in FIG. 1. These files include schematic and layout files starting with small components, and working up to files describing and defining the entire chip. Keeping track of all of these files in a complex Integrated Circuit (IC) design, and verifying that they all match and have been properly tested in a parallel design environment can be very complicated. This is especially true for the design of full sized processors which may require upwards of a thousand different files per design. Yet the cost of not verifying is becoming prohibitive. This has a significant effect on both time to market and product reliability.
FIG. 2 is a flowchart showing the operation of one implementation of the validity checker. The checker is entered, step 200, and the Schematic is verified, step 202. Next, the Layout is verified, step 204, and the schematic is checked for electrical identity with the layout, step 206. If any of these checks fail, the validity check error exits. Otherwise, it normal exits, step 210, indicating that the layout is correct.
FIG. 3 is a flowchart showing the operation of the Check Schematic routine, step 220 in FIG. 2. The routine enters, step 220 and a check is made for more tests, step 222. If there are no more tests to run, the routine returns normally, step 224, indicating success. Otherwise, a search is made for the next test to verify, test 226. If the test is found not to have been run, step 228, the routine error returns, step 232. Otherwise, a check is made whether the test was successful, step 230. If the test was not successfully run, step 230, which may be indicated by a nonzero result or status code, the routine error exits, step 232. Otherwise, the routine loops, again checking for more tests to verify, step 222.
FIG. 4 is a flowchart showing the operation of the Check Layout routine, step 204 in FIG. 2. The routine enters, step 240 and a check is made for more tests, step 242. If there are no more tests to run, step 242, the routine returns normally, step 244, indicating success. Otherwise, a search is made for the next test to verify, test 246. If the test is found not have to been run, step 248, the routine error returns, step 252. Otherwise, a check is made whether the test was successful, step 250. If the test was not successfully run, step 250, which may be indicated by a nonzero result or status code, the routine error exits, step 252. Otherwise, the routine loops, again checking for more tests to verify, step 242.
FIG. 5 is a flowchart showing the operation of the Check If Schematic Matches Layout routine, step 206 in FIG. 2. The routine enters, step 260 and gets the next. Electrical Checker (EC) tests, step 262. If there are no more tests that have been run, step 264, the routine returns, step 266, indicating failure. Otherwise, the EC test is checked to see if it tested the required schematic, step 268, and layout, step 270. If they don't match, the routine loops, getting the next EC test to check, step 262. If it matches both the schematic, step 268, and the layout, step 270, a check is then made whether the Electrical Checker was successful, step 272. If it was successful, the routine returns normally, step 274, indicating that the layout and schematic match. Otherwise, the routine error exits, step 266, indicating failure.
One alternative to the above Check If Schematic Matches Layout routine, step 206 in FIG. 2 is to loop upon failure in step 272 back to step 262, instead of error exiting, step 266. This change allows multiple Electrical Checker runs over the same layout/schematic pair.
FIG. 6 is a block diagram showing the interaction of the most significant components in a more general implementation of the Validity Checker or Audit Engine system. It would be more suitable for larger designs, such as are found in high performance microprocessor development efforts or large team software development projects.
The Validity Checker has three main input files, a Run History File 310, a Buildlist File 312, and a Criteria File 314. The Run History File 312 contains information about each of the Tool Runs 304 executed. It includes identification of the Input Tool Files 302, status from the Tool Runs 304, and possibly identification of the output file 306 generated by the Tool 304. In the example shown in FIG. 1, the Run History File 312 would include the results from the Schematic tests 64, 68, the Layout tests 90, 92, 94, 96, 98, and any tests performed to show electrical identity or equivalence between Schematics 60, 62 and the corresponding Layouts 80, 82, 84, 86, 88. In the case of the files for a specific Schematic or Layout, for example Layout V1#1 80, there would be a separate history entry for each test run 90, i.e. TEST1, TEST2, TEST3, and TEST4.
The Buildlist File 312 is a file that contains information identifying the files contained in an Environment. It identifies Tool Input Files 302, and possibly some Tool Output Files 308. In the FIG. 1 example, one environment would include Schematic V1 60 and Layout V1#1 80. A second environment would include Schematic V1 60 and Layout V1#2 82.
The Criteria File 314 contains the Criteria that a Validate Program 316 uses to evaluate the files in the Environment in the Buildlist 312 against the results of tool runs in the Run History File 314. The Validate Program or Audit Engine 316 applies the Criteria to the files in the Buildlist environment, and generates output 318. This Validate Program output 318 can contain warnings and error messages describing which tests have been executed successfully and unsuccessfully, and which tests have not been run.
The Attachment includes an example of these files. It consists of a sample Buildlist File 312, Criteria File 314, and Run History File 310, and Print output 318 from execution of the Validate Program or Audit Engine 316 utilizing the three input files 310, 312, 314 in the Attachment. It should be noted that an actual Buildlist File 314 for the current generation of RISC processor chips may identify upwards of a thousand Tool Input Files 302 and the Run History File 310 may contain information for hundreds, if not thousands of Tool 304 runs.
FIG. 7 is a flowchart showing the operation of the preferred embodiment shown in FIG. 6. The first operation is to validate the Buildlist 350. In order to be valid, a Buildlist 312 must not include any duplicate copies or versions of the same file. Different versions may be uniquely identified by some filename mask, through use of a version-control system, or through use of checksums. The latter is shown in the Attachment by the use of the "aprsum" program. In the example shown in FIG. 1, Layout V1#1 80 and Layout V1#2 82 could not validly reside in the same Buildlist 312, nor could Schematic V1 60 and Schematic V2 62.
Next, the Criteria Records in the Criteria File 314 are sequentially read and evaluated. In the Criteria File 314 shown in the Attachment, each Criteria Record is identified by the keyword "CRITERIA" followed by the code contained between a matched set of opening ("{") and closing ("}") braces. The primary statements in each criteria record are: FILE.sub.-- PATTERNs, RUN.sub.-- REQs, and FILE.sub.-- REQs. The FILE.sub.-- PATTERN statements identify File Patterns that match files in the Buildlist 312. In the example shown in the Attachment, the first Criteria Record is the DEVICE criteria:
It is matched by a "DEVICE/.*" regular expression in a filename. For example, this FILE.sub.-- PATTERN will match "data/dir3/DEVICE/nmos" in the Buildlist 314 shown in the Attachment.
Following FILE.sub.-- PATTERN statements in Criteria Records are RUN.sub.-- REQS statements. These are named and include the statements contained within a matched set of opening ("{") and closing ("}") braces. The RUN.sub.-- REQS statements contain RUN.sub.-- PATTERN and VALID.sub.-- RUN statements. The RUN.sub.-- PATTERN statements identify processor calls. These are the tool programs used to make or test portions of the environment. In the Attachment example, the first pattern:
matches History Records in the Run History File 310 that have a processor call or tool program name that match the regular expression "lp:.*". This mask matches the processor call in the third entry in the Run History File 310 in the Attachment example (which starts "lp:/tmp.sub.-- mnt/home/anitak/. . . "). The VALID.sub.-- RUN statement determines whether the RUN.sub.-- REQS statement returns a Boolean true or false. A valid run is identified in the Attachment first example by:
Thus, the example RUN.sub.-- REQS statement returns true if either the ExitStatus was zero, OR a Waiver card was present. The "@" in the equation directs that a Warning be printed if that test fails, even if the entire statement is true.
The example above and in the Attached example show testing ExitStatus against zero. This was done solely for simplicity. Much more complex testing is also available. Compound conditionals are supported, and multiple tests can be required for a successful configuration. Also, as noted below, the invention is not limited to ExitStatus. For example, a tool program may attach the number of shorts (#shorts is the number of times power is connected to ground) to its Run History entry. The #shorts in the history record might then be tested, requiring there to be five or less shorts for a valid run.
The final statement in the Criteria Record is the FILE.sub.-- REQS statement. In the first criteria record in the Attachment example validity requires that:
Thus, a run/file combination is valid if either the "lp" VALID.sub.-- RUN returned true, or the "exclusion" VALID.sub.-- RUN did.
Continuing with FIG. 7, if more criteria records exist in the Criteria File 310, step 352, the next Criteria Record is read and interpreted. A list of all the files matching the criteria filemask in the buildfile is created, step 356. In the Attachment example, the list for the DEVICE CRITERIA would include:
data/dir3/DEVICE/MMAA aprsum 58912
data/dir3/DEVICE/nmos aprsum 29137
data/dir3/DEVICE/pmos aprsum 28929
data/dir3/DEVICE/rpmos aprsum 29222
data/dir4/DEVICE/WIDO aprsum 137648
data/dir4/DEVICE/WID1 aprsum 338482
data/dir4/DEVICE/WID2 aprsum 192228
data/dir4/DEVICE/WID3 aprsum 56049
data/dir4/DEVICE/WID4 aprsum 537590
data/dir4/DEVICE/WID5 aprsum 796952
data/dir4/DEVICE/WID9 aprsum 143466
data/dir4/DEVICE/WIDA aprsum 1245861
Next, the Run History File 310 is opened, step 358. The run history records are read one-by-one. A check is made whether there are any more Run History Records in the Run History File 310, step 360. In the Attachment example, Run History Records are separated by "* * *" cards. If not, the program loops back, closing the Run History File 310, step 362, and checking for more Criteria Records, step 352. Otherwise, the next Run History record is read from the Run History File 310, step 364.
The tool entry in the Run History Record is compared with the tool in the Criteria Record, step 366. In the Attachment example, the third Run History Record matches the RUN.sub.-- PATTERN ("lp") in the first RUN.sub.-- REQS in the first CRITERIA Record. If the Tool in this Run History Record does not match the Criteria Record Tool, step 366, the program loops, checking for more Run History Records, step 360.
If the same tool, step 366, a check is made whether the Run History Environment matches the Buildlist Environment, step 368. This can be done by comparing the files in the Run History Record with the files in the Buildlist File List built in step 356. Note that in the Attachment example, the Run History file list is located between a "* *" delimiter and the "* * *" delimiter card discussed above. If not the same Environment, step 368, the program loops, checking for more Run History Records, step 360. One obvious optimization here would be to check each Run History Record one time against the Buildlist 312 environment, eliminating further consideration of those Run History Records with differing Environments.
After determining that the Run History Environment matches the Buildlist Environment, step 368, an inner loop is entered where the files in the Buildlist List created in step 356 are evaluated one-by-one. A check is made whether there are any more files in the list, step 370. If not, the inner loop is complete, and the intermediate loop is repeated, with a check for more Run History Records, step 360.
If there are more files in the Buildlist list, step 370, a check is made whether the next file in the Buildlist list is in the Run History file list, step 372. If the file is not in the Run History file list, step 372, the inner loop iterates, checking for more files in the list, step 372. Otherwise, a check is made whether the run was valid, step 374. If the run was valid, step 374, a success message is printed in the Validate Print 318 file, step 376. Otherwise, a failure message is printed, step 378. In either case, the inner loop iterates, again checking for more files in the Buildlist file list, step 370.
In the Attached example, determination of whether a run was valid for a particular file, step 374, is determined first by the VALID.sub.-- RUN statements in the CRITERIA statements. One example is to check for a run's exit status. There are two RUN.sub.-- REQS statements in the DEVICE CRITERIA record. In the first such statement, a check is made of ExitStatus. Looking at the Attachment example Run History File 310, the first two Run History Records contain an ExitStatus equal to zero, while the third record (the first record matching the "lp" tool) contains an ExitStatus equal to 20.
Different implementations of the above procedure are envisioned. For example the loops may be embedded in different orders. One such enhancement would read Run History File 310 records one-by-one. Each Run History record would be checked against the Buildlist File 312 Environment. If they both are for the same environment, the Criteria File 314 records can be read one-by-one. Each file in the Run History could then be checked against the Criteria File 314 record.
Other implementations are also envisioned. One extension is the support of labeled substrings in the regular expression matching. Thus, when a match is made, the matched filename can be easily split into different substrings. This would allow construction of other filenames on-the-fly from the labeled substrings. The presence of these additional filenames could then be verified in the Run History File 310 records. One usage of this feature is to easily verify that layouts match schematics in an environment that contains multiple distinct layouts and/or schematics.
Another extension is to provide criteria for determining whether an entire design is valid, based on a given Run History 310, Buildlist 312, and Criteria File 314. The primary feature required would be provision of additional levels of Criteria. For example, CRITERIA records could invoke or reference CRITERIA records in addition to RUN.sub.-- REQS statements. An additional feature that would simplify this would be parameterization of Criteria statement calls and statements. This would be especially helpful if combined with the labeled substring facility discussed in the previous paragraph.
The Validate Program or Audit Engine is useful for managing data in concurrent engineering environments where more than one model of a system is being evolved at any given time. An example would be a microprocessor development team, where time-to-market pressures force operations that would otherwise be done sequentially to happen in parallel. For example, static timing analysis may be performed on one configuration of a device, while functional regression testing is occurring on another configuration of the chip. Using this configuration management system, the status of a view (i.e. file), or a group of views, can be checked and validated.
The remainder of this disclosure discusses a method of recording entries in a Run History File 310. One solution is to manually enter the information from each tool run in a Run History File 310. This has all of the disadvantages of manual operations in the computer age: it is labor intensive, and error-prone.
Another alternative is to incorporate code in each Tool 304 that automatically records the information for each Tool run. This is often not practicable since Tools 304 are often purchased from Tool vendors, and such inclusion would involve modification of Tool source code, which Tool vendors are often reluctant to allow. Note that this is compounded because a large development project often uses tools from a number of different vendors.
A third alternative is usage of a custom bill-of-material generator which relies on knowledge about its associated program to operate. A different custom bill-of-material is required for each Tool whose run-time configuration needs to be recorded. This alternative also requires access to source code. Another disadvantage is that the generator can get out-of-sync with its associated tool program, introducing the possibility of errors.
A preferred alternative is to automatically generate the information from system logs or traces. FIGS. 8-12 are flowcharts that together illustrate a UNIX implementation of this alternative. Some version of UNIX is standard on almost all engineering workstations.
The implementation shown in FIG. 8 can best be understood as wrapping a "wrapper" around the execution of each Tool 304. This is done by placing the pathname to the Tool 304 program and command line parameters as arguments or inputs to the "wrapper" program.
The "wrapper" program starts, step 100, by turning on system traces, step 102. The user program is then executed, step 104. This is typically done in UNIX with FORK and EXEC system calls. Upon completion of the program, step 104, the system traces are turned off, step 106, the trace file is processed, step 108, and the program exits, step 110.
The "wrapper" function was implemented under IBM's AIX UNIX operating system utilizing its "trace" facility. Function "trcon" was invoked to turn traces on and function "trcoff" invoked to turn traces off. More recently, equivalent AIX functionality has been offered in "SCTrace", a product offering of SEVone Software, a subsidiary of The Kernel Group, Inc. Note also that the Sun Solaris "strace" function provides similar functionality for that operating system.
FIG. 9 is a flowchart showing the operation of an implementation of the Evaluate Traces routine, step 108, discussed in FIG. 8. It starts, step 120, by finding the Process Ids (PIDs) of the Tool program and its progeny, step 122. Next, corresponding program executions for the PIDs are identified, step 124. Program pathnames and return status's are written to the Run History File 310. Additionally, tool programs using API calls can attach other properties to its run-history entry (e.g. #shorts=5, #warnings=2). These additional properties can also be tested using Criteria Records. Next, the files belonging to the PIDs are identified, step 126, and all of the above is added to the Run History File 310 record. Finally, the wrapper exits, step 130.
FIG. 10 is a flowchart showing the operation of an implementation of the Find PIDs routine, step 122. The routine enters, step 140, and determines the program's PID, step 142. Alternatively, the program can begin with the Tool's PID. The "wrapper's" PID can be easily determined through system calls. The Tool PID is often returned by FORK system calls, as was done to start the Tool program. In any case, a file is opened to store the PIDs, step 144, a search is made for Children PIDs, step 146, the output file is closed, step 148, and the routine returns, step 150. Instead of storing PIDs in a file, they can be stored in memory.
FIG. 11 is a flowchart showing the operation of an implementation of the Search For Children routine, step 146 in FIG. 10. The routine enters, step 160, and outputs the parent's PID, step 162. Note that the PID may be stored in either an output file, or memory. The Trace File is opened, step 164. The trace file entries are searched one-by-one. A test is made for more Trace File entries, step 166. If none exist, the Trace File is closed, step 168, and the routine returns, step 170.
If more Trace File entries exist, step 166, the next Trace File entry is read, step 172. If it is a FORK entry, step 174, the Search for children routine, step 146, is invoked recursively, step 176, with the PID from the FORK trace entry used as the PID in new invocation of the Search For Children routine. In any case, the routine loops, checking for more Trace File entries, step 166. The result of executing the Find PIDs routine, step 122, shown in FIG. 10, and the Search for Children routine, step 146, 176, shown in FIG. 11, is a list of relevant PIDs located either in a file or memory.
FIG. 12 is a flowchart of the operation of the Find Files routine, step 126 in FIG. 9. Its primary purpose is to identify all of the files associated with any one of the PIDs in the PID list created by the Find PIDs routine, step 122.
The Find Files routine starts, step 180, by opening the Trace File, step 182. Each entry in the file is read and evaluated, one-by-one. A Trace Entry loop is entered, and a check is made for More Trace Entries, step 184. If no more entries are found, the Trace File is closed.
If there are more Trace Entries, step 184, the next Trace Entry is read, step 190. The event type or code of the just-read Trace Entry is checked, step 192, and if not the correct type, the routine loops, checking for more Trace Entries, step 184. The "fopen" event type can be used here to identify the opening of files. Otherwise a check is made whether the PID of the Trace Entry matches the PID of any of the PIDs in the saved PID list, step 194. If the PID is in the list, step 194, the pathname is written to the Run History File 310. Often access privileges can be determined from Trace Entries, and these can also be written to the Run History File 310.
For efficiency, not all Trace types need to be enabled. Tracing only those events immediately applicable to the determination of PIDs, files opened or closed, and processor status adds a negligible amount of overhead to the tool execution. On an IBM RS/6000 workstation running under the AIX operating system, by turning on only traces 001, 106, 107, 130, 134, 139, 15b, the "wrapper" overhead was barely noticeable.
As noted above, different computer architectures require slightly different implementations. For example, under Mainframe operating systems, such as IBM's MVS/ESA and Unisys's OS/1100, the relevant information needed for the Run History File 310 can be acquired by reading the system log files searching for a unique JOBID or RUNID. As these operating systems do not FORK semiautonomous processes, step 124 with its associated detail in FIGS. 10-11 is not necessary.
Aside from such factors as disk space, a program's run-time course is affected by environment variable settings, command line parameter settings, and the content of the files read by the program. Determining and recording environment variables and command line parameter settings at run-time can be obtained automatically using this invention without additional knowledge about the program executable, or by altering the executable in any way.
It is useful to any application that requires input about the run-time configuration of a process. An example would be the above described configuration audit system that checks whether or not a particular file configuration has been examined by one or more verification programs.
FIG. 13 is a block diagram of a general purpose computer 20 such as is used to implement this invention. The general purpose computer 20 has a Computer Processor 22 and primary Memory 24 connected either directly, or via a DMA port or Bus 26. Also connected to the Bus 26 are Secondary Storage 30, External Storage 32, a monitor 34, keyboard 36, and printer 38.
Tool Input Files 302, Tool Output Files 306, Run History Files 310, Buildlist Files 312, and Criteria Files 314 are primarily stored on Secondary Storage 32, such as magnetic disk (but may be stored on External Storage 32 or in primary Memory 24). Tool Prints 308 and Validate Program Prints 318 can be either spooled to Secondary Storage 30, or printed on a printer 38. External Storage 32 can be floppy disks, tape, CD-ROM, another computer, or anything with equivalent functionality. Computer programs 33 such as Tools 304 and the Validate Program 316 are initially loaded from External Storage 32 and Secondary Storage 32 into primary Memory 24 for execution by the Computer Processor 22.
An important benefit of this invention is the minimization of errors and cycle time in the design and manufacture of complex Integrated Circuits. The invention significantly reduces these factors by allowing concurrent design while increasing reliability of test coverage. VLSI circuit design is explained in detail in "CMOS VLSI Design, A Systems Perspective" by Neil Weste and Kamran Eshragian, published by Addison, Wesley Publishing, copyright 1985, with an ISBN of 0-201-08222. The manufacture of Integrated Circuits is extensively disclosed in the two volumes of "Silicon Processing for the VLSI Era" by Stanley Wolf, published by Lattice Press of Sunset Beach, Calif. Volume I subtitled "Process Technology" was copyrighted in 1986 by Lattice Press and has an ISBN of 0-961672-3-7. Volume II subtitled "Process Integration" was copyrighted in 1990 by Lattice Press and has an ISBN of 0-961672-4-5. These three books are incorporated herein by reference for the purpose of teaching VLSI circuit design and the subsequent manufacture of Integrated Circuits therefrom.
Embodiments of the invention disclosed above may be implemented as computer software. It must be appreciated that the design and implementation of computer programs or software utilizes successive decomposition. A problem is broken down into smaller and smaller program elements. Higher level program elements are modules, groups of modules, and even programs, while lower level program elements are program statements, instructions, function calls, and system calls. A collection of low level program elements comprise each higher level program element, and a collection of these program elements comprises the next higher level of program elements. This is repeated until you reach the highest level of program elements, which are usually entire programs, or groups of programs.
Those skilled in the art will recognize that modifications and variations can be made without departing from the spirit of the invention. Therefore, it is intended that this invention encompass all such variations and modifications as fall within the scope of the appended claims. ##SPC1##
Claims
I claim:
1. A method for automatically determining a run-time environment of a computer program, said method comprising the steps of: A) turning on a system tracing of one or more event types; B) executing the computer program on a Computer Processor while tracing the one or more event types after turning on the system tracing; C) turning off the system tracing of the one or more event types after executing the computer program; and D) searching a system trace output resulting from the system tracing of the one or more event types to identify events corresponding to the execution of the computer program.
2. The method in claim 1 wherein step (D) comprises: 1) determining one or more Process IDs (PIDs) corresponding to the execution of the computer program; 2) searching the system trace output for one or more selected events corresponding to the PIDs determined in substep (1).
3. The method in claim 2 wherein step (D) substep (1) comprises: (a) inserting an initial Process Id (PID) in a PID list, (b) searching the system trace output for a process initiation event, (c) whenever the process initiation event is found in the system trace output, matching an initiating PID in the process initiation events with one of the PIDs in the PID list, and (d) whenever the initiating PID is matched in subsubstep (c), inserting a corresponding initiated PID in the PID list.
4. The method in claim 3 wherein in step (D) substep (1) substep (d): the process initiation event is the execution of a "fork" system command.
5. The method in claim 2 wherein in step (D) substep (2): at least one of the selected event types corresponds to a "fork" system command.
6. The method in claim 2 wherein in step (D) substep (2): at least one of the selected event types corresponds to an "exec" system command.
7. The method in claim 2 wherein in step (D) substep (2): at least one of the selected event types corresponds to an opening of a file.
8. A method for recording Run History file entries utilizing the method in claim 1 which further comprises: E) formatting a Run History File entry from the events identified in step (D), and F) writing the Run History File entry in a Run History File.
9. The method in claim 8 wherein in step (E): the Run History File entry includes an exit status from the program executed in step (b).
10. The method in claim 8 wherein in step (E): the Run History File entry includes a pathname of the program executed in step (b).
11. The method in claim 8 wherein in step (E): the Run History File entry includes one or more command line parameters to the program executed in step (B).
12. The method in claim 8 wherein in step (E): the Run History File entry includes the pathnames of one or more files opened by the program executed in step (B).
13. The method in claim 12 wherein: each of the one or more patinames for the files included in the Run History File entry is identified with a unique identification to distinguish it from different versions of the file.
14. The method in claim 13 wherein: the unique identification is a checksum.
15. The method in claim 13 wherein: the unique identification is a version number.
16. The method in claim 12 wherein: the Run History File entry includes a file access mode for each of the one or more pathnames corresponding to the files opened by the program executed in step (B).
17. The method in claim 8 wherein in step (E): the Run History File entry includes an identification uniquely identifying the execution of the program executed in step (B).
18. The method in claim 8 wherein in step (F): the Run History File is stored as a flat file on Secondary Storage.
19. The method in claim 8 wherein in step (F): the Run History File is stored as a database on Secondary Storage.
20. A method for automatically recording Run History file entries corresponding to a run-time environment of a computer program, said method comprising the steps of: A) turning on a system tracing of one or more event types; B) executing the computer program on a Computer Processor while system tracing the one or more event types after the system tracing is turned on in step (A); C) turning off the system tracing of the one or more event types after executing the computer program; D) searching a trace output resulting from the system tracing of the one or more event types to identify events corresponding to the execution of the computer program, said step comprising the substeps of: 1) determining one or more Process IDs (PIDs) corresponding to the execution of the computer program, said substep comprising the substeps of: (a) inserting an initial Process Id (PID) in a PID list, (b) searching the system trace output for a process initiation event, (c) whenever the process initiation event is found in the system trace output, matching an initiating PID in the process initiation event with one of the PIDs in the PID list, and (d) whenever the initiating PID is matched, inserting a corresponding initiated PID in the PID list, and 2) searching the system trace output for one or more selected events corresponding to the PIDs determined in substep (1); E) formatting a Run History File entry from the events identified in step (D); and F) writing the Run History File entry in a Run History File stored on Secondary Storage.
21. A wrapper computer program for automatically determining a run-time environment of an object computer program comprising: A) a program element for turning on a system tracing of one or more event types; B) a program element for executing the object computer program on a Computer Processor while system tracing the one or more event types after the system tracing is turned on; C) a program element for turning off the system tracing of the one or more event types after executing the object computer program; and D) a program element for searching a system trace output resulting from the system tracing of one or more event types to identify events corresponding to the execution of the object computer program.
22. The program in claim 21 wherein program element (D) comprises: 1) a program element for identifying one or more Process Ids (PIDs) corresponding to the execution of the object computer program; 2) a program element for searching the trace output for one or more selected events corresponding to the PIDs identified in program element (1).
23. The program in claim 22 wherein program element (D) subelement (1) comprises: (a) a program element for inserting an initial Process Id (PID) in a PID list, (b) a program element for searching the trace output for process initiation events, (c) a program element for matching an initiating PID in the process initiation events with one of the PIDs in the PID list whenever a process initiation event is found in the trace output, and (d) a program element for inserting a corresponding initiated PID in the PID list whenever an initiating PID is matched.
24. The wrapper program in claim 23 wherein in program element (D) subelement (1) subelement (d): the process initiation event is the execution of a "fork" system command.
25. The wrapper program in claim 22 Wherein in program element (D) subelement (2): at least one of the selected event types corresponds to a "fork" system command.
26. The wrapper program in claim 22 wherein in program element (D) subelement (2): at least one of the selected event types corresponds to an "exec" system command.
27. The wrapper program in claim 22 wherein in program element (D) subelement (2): at least one of the selected event types corresponds to an opening of a file.
28. A wrapper computer program for automatically recording Run History File entries utilizing the program elements in claim 21 which further comprises: E) a program element for formatting a Run History File entry from the events identified in program element (D), and F) a program element for writing the Run History File entry in a Run History File.
29. The wrapper program in claim 28 wherein the Run History File is stored as a flat file on Secondary Storage.
30. A wrapper computer program for automatically recording Run History file entries corresponding to a run-time environment of an object computer program comprising: A) a program element for turning on a system tracing of one or more event types; B) a program element for executing the object computer program on a Computer Processor while system tracing the one or more event types; C) a program element for turning off the system tracing of the one or more event types after executing the computer program; D) a program element for searching a system trace output resulting from the system tracing of the one or more event types to identify events corresponding to the execution of the object computer program, said program element comprising: 1) a program element for determining one or more Process IDs (PIDs) corresponding to the execution of the object computer program, said program element comprising: (a) a program element for inserting an initial PID in a PID list, (b) a program element for searching the system trace output for process initiation events, (c) a program element for matching an initiating PID in the process initiation events with one of the PIDs in the PID list whenever a process initiation event is found in the system trace output, and (d) a program element for inserting a corresponding initiated PID in the PID list whenever an initiating PID is matched, and 2) a program element for searching the system trace output for one or more selected events corresponding to the PIDs determined in program element (1); E) a program element for formatting a Run History File entry from the events identified in program element (D); and F) a program element for writing the Run History File entry formatted by program element (E) in a Run History File stored on Secondary Storage.