WO1997032250A1 - Interactive software development system - Google Patents
Interactive software development system Download PDFInfo
- Publication number
- WO1997032250A1 WO1997032250A1 PCT/US1997/002177 US9702177W WO9732250A1 WO 1997032250 A1 WO1997032250 A1 WO 1997032250A1 US 9702177 W US9702177 W US 9702177W WO 9732250 A1 WO9732250 A1 WO 9732250A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- program
- code
- objects
- incremental
- files
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3664—Environments for testing or debugging software
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/48—Incremental compilation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
Definitions
- the present invention relates to computer aided software engineering, and more particularly to an interactive program development system which replaces prior art compilers, linkers, and debuggers with a single program.
- the present invention is particularly applicable to object-oriented programming.
- the programming system of the present invention not only operates at speeds greater than prior art compilers, but more* 1 importantly it precludes the need to halt execution of the program in order to correct programmatic errors during software development and maintenance.
- the present invention enables interactive "real-time" debugging of a program as it is compiled ("built") without the need for batch recompilation, re-linking, re-loading or the need for the developer to re-create error states.
- Developing a computer software product (hereafter, "software") is a complex cyclical process which requires significant expenditure of time on the part of the software development team (hereinafter, the "developer”).
- This development process is often referred to in terms of "edit - compile -link - run", or “edit - compile- test”, which refer to some of the major steps of the development process.
- OOL object oriented programming language
- some languages which support such object oriented programming are C+ + and Smalltalk.
- each of the source code modules must be linked together to form the image of the complete program (hereinafter, the "image").
- This linking process typically includes a "fix-up” which, among other things ensures that each of the modules is correctly addressed and addressable.
- the image must be loaded and executed.
- the program typically halts execution or behaves erratically. Traditionally, this means that program execution halts or must be halted, before a separate program, a debugger, is invoked to assist in determining the error to the faulty executable program.
- WO 95/00901 and WO 95/00904 to Taligent, Inc. teach an incremental build system and linker system. Taken in sum, these references attempt to replace the traditional batch-mode programming systems. In a typical compiler symbol table, references to other data often make up more than half of the contents of data items. Thus, reference translation presents a significant source of computational overhead.
- Ids as taught in the '901 reference.
- the incremental builder taught by the '901 reference teach modeling a computer program as project component and a collection of building components, each representing a single compilable language element. Those components which provide the model for a computer program are stored for access during the build process.
- the stored components are accessed in sequence, and using a compiler, dependencies associated with a component are calculated to develop client and reference lists. Finally, the components are compiled to build the computer program using the properties of the components along with the compiler dependencies.
- the '901 reference thus reads on a system in which the program is not defined in files, but in terms of components, addressable by means of Ids.
- the '901 reference teaches a system which does not have the previously discussed translation problem, but replaces it with a number of independently addressable (and reasonably complex) components, the building and utilization of which are a major source of computational overhead. These contribute to the lack of computational efficiency of this system.
- the '904 reference teaches an incremental linker which utilizes the independently addressable components created by the Incremental Builder of the '901 reference to link only those components which have been modified during the edit phase of the development cycle.
- the system taught by the '901 and '904 references again represent an incremental improvement to the steps of the traditional software development cycle. The necessity to perform those steps remains unchanged. From the preceding discussion it will be appreciated that significant effort has been expended on improving the efficiency of several of the steps of the software development cycle. What has not been realized, up to this time, is the significant increase in programmer efficiency which must ensue by reducing the number of the steps of the development cycle.
- a development system which re-defines the development cycle by presenting the developer with fewer steps during each iteration of the cycle would present significant economies in time and expense over prior art schema. Further economies would be realizable if the system were more efficient, and presented faster execution speeds, than prior compilation schemes. If only some methodology could be found which enables a developer to debug and edit source text interactively, without halting program execution, the methodology would at once obviate the need to re-create the error state and verify the efficacy of the fix. Accordingly, profound and hitherto unattainable levels of developer productivity would be realized.
- an interactive computer program development system that enables real-time debugging of a program as it is compiled without the need for batch recompilation, re-linking, re-loading or the need for the developer to re-create error states.
- this interactive system includes a computer system having a debugger resident therein, and having a given set of source code files.
- a developer invokes the debugger for the first time for a given set of source code files
- an incremental builder resident in the system is invoked which translates the source code files into code objects and their corresponding intermediate language (IL) symbols.
- the code objects and IL symbols are stored in a resident persistent symbol table.
- a resident incremental imager utilizes the code objects and IL symbols to form run-time code objects.
- the incremental imager then links together run-time code objects forming a program image which is executable.
- the actions of the program image and the computer program are coordinated through a probe and a runner.
- the probe executes in the incremental imager process and the runner executes in the process of the built program.
- the image is executed, and the image embodies the program simultaneously in two separate threads of execution using memory-mapped data.
- Incremental Builder which produces a novel type of translated structure, the code object
- Incremental Imager which forms the program image from code objects and their respective intermediate language (IL) symbols stored in a persistent symbol table.
- the program is executed in a separate thread of execution in a separate, protected address space.
- a proprietary debugger interactively assists the developer in debugging the program under development in virtual real time using the formed image and the executable program.
- the developer invokes an extractor which converts it into an executable file (e.g., an ".EXE" file).
- Thread of execution refers hereinafter to a logical structuring of a program - each thread of execution has its own sequence of instructions which it will execute.
- An "address space” is a mapping of memory addresses that are unique to a specific set of threads. Each address space and its associated set of threads define a "process”.
- a code object is the fully translated machine language implementation of a function definition, or the initial value of a variable, which refers to IL symbols representing other code objects by means of direct memory reference as opposed to Ids.
- Code objects and IL symbols are low level data structures used to create an image, i.e., the "program”.
- Code objects contain the description of those symbols to which the function refers.
- the IL symbol contains a description of those code objects which refer to the function.
- the code objects and their respective IL symbols, as well as language symbol table objects are stored in a persistent symbol table.
- the Incremental Builder would determine that no previously built version exists in the persistent symbol table, and would translate the files in toto. Where the source code has been edited, and hence previously incrementally built, the Incremental Builder determines that a previously built version exists in the persistent symbol table, and would only translate those portions of the source code whose code objects were affected by the edited portions of the original source code.
- the persistent symbol table takes the form of an object-oriented database. Note that in the present context, persistent means that it is capable of being stored to a persistent data storage device, not necessarily that such storage has actually occurred. Of course, when a developer ceases work on a project under development, for instance at the end of the work day, the persistent symbol table could well be stored in such a persistent storage device. Prudent computing practice would usually so dictate.
- the database is not discarded when system operation is terminated.
- IL symbols and their corresponding code objects are stored in memory.
- code objects are duplicated by the Incremental Imager to form the image as run-time code objects.
- the program is executed under a separate thread of execution in a separate, protected address space.
- the probe and the runner coordinate the actions of the development system and the image (which embodies the program being developed).
- the probe executes in the Imager process and the runner executes in the process of the built program. Should an error be detected as the program is executed, program execution under the runner is halted.
- the operating system transmits data relative to program failures to the debugger, which translates this data into information relating to which line or lines of source code caused the failure. When the debugger notifies the developer of the failure, this information is passed to him or her.
- the developer edits the source code file to obviate the program failure, he can instruct the system to incrementally compile and update the modified portions of the program, resulting in new IL symbols and code objects which implement those modifications.
- the Builder incrementally compiles only those program units which relate to the edited source code. From the new code objects and IL symbols the incremental imager forms an updated image of the program, and program execution continues. Note that the steps required by the prior art of linking and loading source code to first update the .EXE file and then of re-creating the exact error state which caused the failure are eliminated.
- .EXE file is the image used by a traditional development system, and by the underlying operating system to start an application process.
- .EXE files are very useful for production-level distribution of software: indeed they are still necessary in order to produce a stand-alone software product. What is no longer necessary is the need to use .EXE files in the software development process, for which they are not well suited due to their static nature.
- Code objects resident in the persistent table are persistent and are not modified as a result of system termination, debugging or other programmer action.
- a function (or data) definition is recompiled, a new code object representing the new definition is stored in the persistent symbol table, and the function's (or data's) IL symbol is updated to point to the new code object.
- the system of the present invention presents several productivity advantages over prior art translators.
- a major advantage is that the system of the present invention enables the programmer to change the program while the program process is still “live”. This obviates the need to stop the program, debug it, edit the source code, batch recompile, and to recreate the error state which caused the "bug" in order to verify the efficacy of the fix. It further completely obviates the need for re-linking and re-loading the program.
- a second major advantage of the image formation scheme detailed herein is that a program developer can run a program until it crashes, correct those lines that caused the crash, and continue. Once the source code line which caused a program crash is modified and corrected, the system continues in operation without further developer input until the next system crash. In this manner, once the developer corrects source code errors, the crash can be said to virtually have not occurred.
- the Incremental Builder generates code objects as opposed to object files. This fact is central to the system of the present invention being able to compile pieces of files, producing code objects only for new declarations or those source code lines which have changed.
- a second concept central to the operation of the Incremental Builder of the present is that it derives the structureof what is represented in the source file and then divides the source file into program units which can be effectively incrementally recompiled.
- the division to program units is coarse enough so that memory requirements are small enough to be practical for current computer systems and fine enough for very fast response.
- traditional debuggers usually contain an interpreter which, upon request by the developer, evaluates expressions during program execution. Some special-case expressions, (e.g. function calls) are in fact evaluated in the real application process by executing machine instructions.
- the debugger of the present invention uses the actual compiler to produce a small code object, which is dynamically inserted into the incremental image, and executed directly. This enables the programmer to go beyond mere interactive evaluation of simple expressions and gives him the ability to amend his program with expression evaluations and statement executions that are integrated into his program. This is performed at the same speed as any other part of the program.
- the debugger of the present invention uses the compiler to build a code object for the condition, incrementally updates the image, and inserts code at the point in the program where the debugger is supposed to break to evaluate the condition directly in the application process, at full speed. Only when the condition is true does the application actually stop, and involve the debugger. None is hidden from the user - the debugger isn't doing anything "behind his back". Further, the conditions may be arbitrarily complex.
- condition inte ⁇ retation is also much slower than condition execution.
- the debugger of the present invention tests the condition as a part of the application, and does not suffer this severe performance penalty. This results in much better turn-around time for conditional breakpoints, which are now generally avoided by programmers due to their poor performance and the fact that the available conditions are often too trivial to be of any use.
- the debugger feature of the present invention is inherent in system design and is not a separate module. Therefore, the compiler and the debugger cannot disagree on the meaning of anything. Furthermore, this debugging schema is much faster than those of prior art debuggers. Another feature of the debugging schema of the present invention is that it does not require termination of programming execution to effect debugging, or restarting once debugging is completed.
- the system of the present invention enables debugging to start and stop at any point during program development. For instance, if the program attempts to execute an undefined function, the system generates a dialog that gives the developer an opportunity to define the function. The developer enters the function and the system compiles it, updates the image, and continues execution by restarting only the function call instruction, not the entire program.
- Figure 1 is a diagram illustrating a temporal comparison of the software development cycle according to the present invention compared to both the traditional view of such a cycle and the improvements thereto obtainable using incremental technology alone.
- Figure 2A is a block diagram of a computer system on which this software development system of the present invention operates.
- Figure 2B is a flow diagram of the software development system of the present invention.
- Figure 3 is a diagram illustrating the properties of a generic program object according to the principles of the present invention.
- Figure 4 is a diagram illustrating the properties of a generic program unit.
- Figure 5 is a diagram illustrating the properties of a declaration program unit.
- Figure 6 is a diagram of the properties of a source file program unit.
- Figure 7 is a tabulation chart of an exemplary first source file A.
- Figure 8 is a tabulation chart of an exemplary second source file B.
- Figure 9 is a tabulation of a modified version of exemplary source file A.
- Figure 10 is a diagram illustrating the incremental building of a program unit, program objects and IL symbols responsive to source file A.
- Figure 11 is a diagram illustrating the incremental building of program units, program objects, IL symbols and code objects responsive to source file B subsequent to the incremental building of source file A.
- Figure 12 is a diagram illustrating the incremental re-building of affected program units, program objects, IL symbols and code objects responsive to modification of source file A.
- Figure 13 is a diagram illustrating the use of the code objects and IL symbols in forming the program image.
- Figure 14 is a diagrammatic representation of the sequential formation of code objects, relocation arrays and run-time code objects responsive to an IL symbol.
- Figure 15 is a diagrammatic representation of shared memory allocation using the probe and runner.
- Figure 16 is a diagrammatic representation of the creation of the run-time image of the program.
- Figure 17 is a diagrammatic representation of the mechanism for ensuring that changes made to a code object are properly addressable by a dependent runtime code object.
- a file embodies, in the broadest sense, a stream of program text, e.g., source text. It will be immediately apparent to those of ordinary skill in the art that this definition includes traditional file- oriented structures, but further comprehends, for instance, undifferentiated data streams.
- Program As used in the description of the system of the present invention, a program consists of a set of files, the declarations contained therein, and a description provided by the developer of the relationships between the program files. This description is referred to as a 'project'.
- Declaration A declaration in C+ + , or any declarative programming language, is a smaller unit of the program description than a whole file. Program declarations typically refer to each other, and form a network of dependencies herein called a dependency graph. It should be noted that this term has an altogether different meaning than the term 'dependence graph', in common use in compiler optimization theory.
- Declarations are of two fundamentally different types: those declarations which have only a compile-time representation, and those that have also a run ⁇ time representation.
- the type of a given declaration will depend on the language, but in the C+ + programming language, examples of the former are typedefs, enumeration type specifiers and function declarations. In the same language, the latter are exemplified by variable definitions, function definitions, and, to some extent, class definition types.
- Program Unit The smallest entity which is compiled at one time.
- a program unit is, however, more than a simple declaration.
- Each program unit contains one or more declarations.
- Program units represent pieces of source files, not independent program entities.
- a program unit is similar, but not equivalent, to a 'component' in the previously discussed '901 and '904 references. Unlike those "components", a program unit is not an independent article that can be named or referred to by any means other than from other program units. Therefore, program units have far fewer properties than do components, and are hence more efficient to form and utilize. Further, program units are subject to a strict sequential ordering within a file, while components are not. Another distinction between the '901 components is that program units are not referred to by ID.
- program units are referred to by direct memory reference.
- the difference is similar to looking up a phone number in a phone book ⁇ whereas the '901 reference makes note of the name of the person to call in a given situation, and therefore the phone number must be looked up every time it needs to call the person, the present invention notes the person's phone number, and doesn't care who is called, since it is known that the right number is being called.
- Symbol Table The symbol table is the central and fundamental repository of information about the program that the compiler gathers from the program constructor in terms of relations between files, or deduces from the program text itself as it compiles its program units. While all known compilation systems have a symbol table, the system of the present invention utilizes the symbol table to store more information therein than in any known prior compiler.
- a table is normally a vector of homogeneous records, each with exactly the same fields as the others.
- a compiler symbol table is simply a large set of heterogeneous data objects, and for which relationships are described. These relationships are defined by direct memory references.
- Persistence Primary memory, such as random-access computer memory (e.g., RAM), is normally allocated and made available to a mnning program in such a fashion that once a first program terminates, the memory is allocated to, for instance, a second program, and the contents of the memory lost. Thus, should the first program be restarted, the same memory is no longer available to the program, and must be reallocated. However, the memory will most likely not have the same contents any longer. In fact, most operating systems take care to make sure that it does not, so that the several programs operating on the computer will not mistakenly rely on memory retaining its contents between invocations. Most secondary memory devices, however, including mass storage devices such as hard disks or tapes, do not have this property.
- RAM random-access computer memory
- Secondary memory devices are often referred to as persistent memory, and are consistently used by all but the most trivial programs to store data from invocation to invocation.
- the system of the present invention is not such a trivial program; neither are most compilation systems.
- Current compilation systems typically store only the end result of compilation in this mass storage in the form of linkable object files and other auxiliary files.
- the system of the present invention stores not only the end result of the compilation process in the form of IL symbols and code objects, but many of the intermediate data structures as well.
- the system of the present invention internally processes the program definition by compiling one program unit at a time, hereby producing a heterogeneous data structure herein referred to as 'intermediate language' (IL).
- IL 'intermediate language'
- IL data structures there are two major groups of IL data structures: symbols and operators.
- symbols and operators are used to describe function definitions and initial values of variables.
- the former are used to describe declarations of both functions and variables.
- a code object represents a function or data definition as a sequence of bytes in the form required by the CPU architecture of the target processor.
- a code object includes a set of relocations, each of which specifies that a pointer value within the code object must point to the code object that is the definition of a specific IL symbol in order to load the code object as part of an executable program.”
- code objects and intermediate language symbols are stored in persistent memory as a persistent symbol table.
- Code objects refer to IL symbols by direct memory reference as opposed to by name or by Id. This again, has significant performance advantages over both traditional systems and the incremental technology previously discussed. Since the system of the present invention utilizes direct memory references as the code objects are formed, no linking process is necessary. The system of the present invention therefore performs linking as a by-product of compilation, thereby eliminating the linker entirely.
- Executable Files An executable file is a complete representation of a translated program, with all references between code objects resolved, and in a form expected by the underlying CPU architecture and operating system. In other words, an executable file is a persistent representation of the program itself, rather than its data. This is typically what a traditional linker or an incremental linker produces. In the system of the present invention, once program editing is complete, the developer causes execution of an extractor which produces an executable file. This extractor therefore performs some of the same functions as the separate linker taught in the prior art. Extractor: A traditional linker collects object files into an internal data structure. Thereafter, the linker traverses the data structure to generate an exectuable file. In contrast, the extractor of the present invention performs essentially the same function and operates in essentially the same way as the second phase of a traditional linker, except that the inputs to the extractor are code objects and IL symbols, as opposed to object files.
- Program Loader is a special functionality of most operating systems that brings an executable file into primary memory, and starts the program under development. This functionality is typically provided by the operating system, and is leveraged by the system of the present invention as well as other compilation systems.
- the system of the present invention embodies the program under development in a proprietary executable format, and not in a file for reasons which will be later explained.
- the system of the present invention further includes a program element referred to as the Runner, which operates in conjunction with the Imager taught herein to perform the loading function.
- the proprietary executable format and its corresponding loader are used only when a program is being developed.
- the predefined executable format appropriate to the target architecture e.g. as an ".EXE" file
- the program loader supplied with the corresponding operating system are used.
- a process has three major properties: a program image, which defines the paths of execution of the program; an entry point, which is the location in the program's image where execution is to begin; and an address space, which is a range of memory locations that are unique for that process, and not accessible to other processes.
- Persistent storage files are not necessarily unique to one program. Two simultaneous processes may access the same persistent storage at the same time, manipulating the data stored therein to share information.
- Shared Memory Modern operating systems including, by way of example but not limitation, Unix and Windows NT / Windows 95 have another means of sharing data by sharing primary memory. This concept is commonly referred to as 'shared memory.' The system of the present invention places the executable image in shared memory rather than in a file. The proprietary program loader taught herein can not only set itself up to share memory with the compilation system, but can locate the process entry point at a specified location in shared memory instead of in an image file.
- Run-time Code Objects As previously discussed, code objects are stored persistently, and are used to form the program image. References between code objects are not in a form suitable for execution on computer hardware. These references must therefore be translated again. In order not to have to modify the code objects for the pu ⁇ ose of forming a runnable program image, and then have to restore to the code objects their original contents, this invention makes copies of them in non-persistent memory, where the program image is formed. These non-persistent code objects are termed run-time code objects. Each run-time code object for a function definition has one instruction more than the corresponding code object, an instruction which is non-essential to the program itself, but very essential to the incremental build process.
- a branch instruction is written therein that initially branches to the next instruction, which is the first instruction of the function itself.
- the instruction does not affect the program logic at all.
- the new code object is either copied into the same run ⁇ time code object as the first, or, if it does not fit, or if an activation of the first run-time code object exists, copied into another run-time code object. If the latter is the case, the branch instruction in the first run- time code object is modified to branch to the first instruction (also a branch instruction) of the new run-time code object. This ensures that all saved references to the old run-time code object are still valid, since after branching there, the program will immediately branch to the new run-time code object.
- Incremental Imager To form the program image in shared memory, the system of the present invention uses something referred to herein as an incremental imager. This takes code objects, copies them into run-time code objects, which are placed in shared memory, and links them together forming a program image which is ready to execute. Rather than having the program loader be passively waiting for the image to be complete, and then load it, the program loader of the present invention takes an active part in the image building process.
- Debugger The term 'debugger' traditionally refers to a program that is used to control the execution of another program, in its own process.
- the compiler translates source text into object files, which are linked together into an executable image file by a linker.
- the compiler and the linker are independent programs, and each execute in different processes.
- the program is then either run directly by the program loader, or by the program loader under the control of a debugger. Once a bug is found, the program is terminated by the debugger, the source text can then be modified or edited by the developer, and the process starts all over.
- the reason that the program has to terminate is that normal program loaders don't allow the image file to be modified while it's in use by a process.
- the incremental builder performs the tasks of the compiler and most of the duties of the linker.
- the incremental builder, the incremental imager, and the debugger all execute in the same process, and the program loader of the present invention allows the image, which is not in a file, to be modified without having to terminate the program.
- the incremental builder of the present invention significantly reduces the time required to fix a program failure by reducing compilation time and eliminating the time to perform linking, loading (since the image is built in shared memory), and error state recreation time (since the program does not have to be restarted, but can sit waiting in the error state until the fix is in place). Once the fix is effected, program execution continues as though the error had never existed.
- FIG. 1 A time-line comparison of the advantages presented by the system of the present invention is shown at Figure 1.
- Prior art systems require that the executable image be kept in a file that cannot be modified (updated) while the program process is still "live”. This requires therefore that in order to effect any changes to the system , it must be stopped and restarted to effect program updates.
- the system of the present invention does not place the executable image in a file, but in shared, mapped memory. The image is thus made available for simultaneous manipulation (by the Imager) and execution (by the Runner). As shown in Figure 2A, the system of the present invention operates on
- CPU 50 display monitor 52, memory system 54 and input device 56.
- CPU 50 preferably is an Intel Pentium; display 52 preferably is a Super- VGA Monitor; memory 54 preferably includes DRAM and magnetic disk storage; and input device 56 includes both a keyboard and a mouse and related interface subsystems.
- FIG 2B an overview of the program of the present invention is shown.
- the incremental builder 4 is invoked which translates source code files 3 into code objects and their corresponding IL symbols.
- the code objects and IL symbols are stored in a persistent symbol table 5.
- Persistent symbol table 5 may be implemented in any type of memory device.
- An incremental imager 6 utilizes the code objects and IL symbols to form run ⁇ time code objects. Incremental imager 6 then links together run-time code objects forming a program image which is executable. The actions of the imager and the program are coordinated through a probe 7 and a runner 8. The probe 7 executes in the incremental imager process and the runner 8 executes in the process of the built program. Thus, the image and the program are executed simultaneously in two separate threads of execution using memory-mapped data.
- a principal aim of the incremental builder of the present invention is to minimize the compilation effort and time required to construct a complete compiled representation of a computer program after a change to the program's source text, without requiring a specialized representation of program source (e.g.
- Program source text typically specifies an interface, an implementation, or both.
- An interface specifies the behavior of one part of a program so that it can be used by another.
- An implementation provides the specified behavior.
- Most programming languages provide a way of making interfaces accessible to separately-compiled source.
- the principles of the present invention are applicable to the compilation of any computer programming language with a facility for logically including interfaces specified in one compilation into another. This facility is termed named-translation inclusion, and is included in many programming languages. By way of illustration but not limitation such languages include Ada, Modula-3, and Java.
- One feature of the present invention is that it adds named-translation inclusion to the C + + programming language.
- Standard C+ + uses lexical file inclusion. This means that source code to be included in more than one compilation is compiled as a part of each such compilation. Clever C+ + implementations can reuse the results of compiling a set of lexically-included files in several compilations, but must completely recompile the entire set if any one lexically-included file changes.
- a partial ordering orders groups of entities, allowing any order within a group.
- a preferred embodiment of the present invention employs a partial compilation order for source files-typically, several files can be compiled simultaneously ⁇ and so can effectively utilize all available processors in a multiprocessing computer.
- Each ProgramObject P has the following properties:
- Signature Creation An encoding of the meaning of the ProgramObject, termed herein a Signature.
- a Signature in a preferred embodiment of the present invention, is a 64-bit hashing of a string representing the logical properties of the ProgramObject. The possibility of two different strings hashing to the same Signature is sufficiently unlikely as to be statistically insignificant.
- a pseudocode representation of one signature creation methodology is as follows: Signature Creation:
- Hash text string End.
- X The logical properties of X are that it is named "X”, it is a data member of class "C”, it is of type signed int, it has an offset of zero, and has a protection of private.
- One possible encoding of these properties is the string: "XprivatesignedintCdataO”.
- XpSICDO an encoding of the properties of this data member is representable as: "XpSICDO”.
- An entire (lexically-included) source file A macro;
- a tag, function, typedef, or data member of a class Each program object is contained by a program unit.
- a program unit is the smallest entity which is compiled at one time by a preferred embodiment of the present invention.
- Different programming languages may impose differing structures which require the formation of program units.
- each of the following constitutes a program unit: An entire file; A file scope declaration; or A namespace scope declaration.
- One of the requirements of the Incremental Builder of the present invention is to recognize all program objects. For each program object, the builder creates an internal representation of the program object called a
- ProgramObject and associates it with an internal representation of the containing program unit called the ProgramUnit object of the containing program unit.
- Program Units may be further classed as either DeclarationProgramUnits or
- SourceFileProgramUnits Each ProgramUnit has the following properties: A Requires Compilation flag, which can have the value true or false.
- a DependsOn set which contains the ProgramObjects used in the compilation of the ProgramUnit.
- SourceFileProgramUnit includes:
- Program source text consists of separately-compilable text files (source files) which may be edited by any text editor.
- a source file that specifies interfaces usable by other source files defines a named translation.
- a source file that uses interfaces specified by other source files includes the relevant named translations (by name) in its compilation.
- the incremental builder of a preferred embodiment of the present invention creates a Translation. This translation is named or unnamed as appropriate. Including a translation in a compilation recursively includes all translations included in the compilation of the translation.
- a source file A defining translation AA must be compiled before source file B if the compilation of B includes AA.
- This rule defines a partial compilation order for the source files of a program. Any set of source files whose compilations are not ordered by this rule can be compiled in any order or simultaneously.
- the syntactic elements are built in the order specified by the programming language definition. For the C+ + programming language, this corresponds to the lexical ordering of the source text.
- Every SourceFileProgramUnit requires building.
- the incremental builder builds the source file represented by each SourceFileProgramUnit in an order that obeys the partial build order, stopping when no unbuilt source files that don't include unbuilt named
- the program builder For each source file that builds without error, the program builder marks the corresponding SourceFileProgramUnit as not requiring building. Every DeclarationProgramUnit in each such SourceFileProgramUnit is marked as not requiring building.
- the incremental builder of a preferred embodiment of the present invention rebuilds only those program units whose source text is edited or that depend on one or more program objects whose logical properties have changed. This is done by marking the SourceFileProgramUnit of each source file whose text has changed (or that lexically includes a source file whose text has changed) as requiring compilation. This is done by setting the Requires Compilation flag to true.
- the incremental builder then traverses all SourceFileProgramUnits in compilation order. For each SourceFileProgramUnit:
- step 2 did not determine any portion of the declaration to contain malformed source code, mark the Declaration Program Unit as not needing building.
- the rebuilding of a Declaration Program Unit is accomplished as follows: 1. Delete the Declaration Program Unit from the Dependents set of each element of its Depends On set, and then clear the Depends On set. 2. Compile the text of the Declaration Program Unit to produce a list of Program Objects.
- step 2 did not determine any portion of the declaration to contain malformed source code, mark the Declaration Program Unit as not needing building.
- Code Objects may be represented in pseudocode form as follows:
- AST defines FD
- generate IL to represent the definition and then perform code generation on the IL to produce a code object.
- a first source file A, 1098 declares class C and declares data member X to be of type integer and declares member functions Fred and Barney to take no arguments and return an integer.
- Source file B defines the functions Fred and Barney.
- Function Fred is defined to return the value of the X member of the C object for which Fred is invoked.
- Barney is defined to return the result of invoking Fred for the C object for which Barney is invoked.
- Figure 9 represents a modification to source file A previously shown at
- Program unit 1100 represents the smallest individually compilable element contained within source file A, 1098.
- the creation of program unit 1100 causes the creation of program objects 1110, 1120, and 1130.
- Program object 1110 represents the declaration of data member X and contains a signature, in this example 101, and a dependents set, whose initial state is empty.
- the declaration for the function Fred is embodied in program object 1120 also has a signature, in this example 37, and a dependents set which is initially empty. Because program object 1120 represents a function declaration, it will result in the creation of an IL symbol.
- the pointer in the IL symbol field in program object 1120 is set to point to IL symbol 1140.
- IL symbol 1140 contains pointers to an old definition and a new definition both of which are, at this time, set to null.
- the function declaration for the function Barney results in the creation of program object 1130 which, in this example, has a signature value of 483, and a dependents set which is initially empty.
- source file A has resulted in the creation of one program unit which causes the creation of three program objects.
- Program unit 1160 represents the syntactic definition of the function Fred, previously shown in Figure 8.
- Program unit 1170 represents the syntactic definition of the function Barney also shown in source file B.
- program units 1160 and 1170 each create one program object, 1180 and 1190 respectively, and the pointers defined in the program objects field of program units 1160 and 1170 point to program objects 1180 and 1190.
- Program object 1180 is the program object representing the definition of the function Fred previously declared by program object 1120, and as such points to IL symbol 1140 which, it will be recalled, was created responsive to the declaration of the function Fred by program object 1120.
- program object 1190 represents the definition of the function Barney previously declared by program object 1130, and again program objects 1130 and 1190 each contain pointers to the IL symbol
- the incremental builder detects dependencies on program objects 1110 and 1120. Accordingly, the depends-on set of program unit 1160 includes pointers to program objects 1110 and 1120 (as shown along pointer line D), and the dependents sets of 1110 and 1120 are each augmented to include a pointer to program unit 1160.
- program unit 1170 depends on program objects 1120 and 1130. Accordingly, the depends-on set of program unit 1170 includes pointers to program objects 1120 and 1130 (as shown along pointer line C), and the dependents sets of 1120 and 1130 are each augmented to include a pointer to program unit 1170.”
- IL symbol 1150 remains unchanged. Because program object 1110 is not rebuilt with an identical signature, each program unit in its dependents set must be rebuilt. Therefore, program unit 1160 is rebuilt, which causes program object 1180 to be rebuilt and code object 1220 to be created.
- IL symbol 1140 is updated as follows: its old-definition field is set to the prior value of its definition field (i.e. to point to code object 1200) and its definition field is set to point to code object 1220. Program unit 1170 and program object 1190 are not rebuilt. After program object 1180 is rebuilt, IL symbol 1140 is updated as follows: the definition pointer is changed from the relocations field of code object 1200 to the relocations field of new code object
- the Dependents field of the program objects e.g. , 1110
- the depends on field of the program units e.g. , 1160
- the actual list of pointers, and the several pointers referred to therein, have been omitted from the figure elements representing program units.
- the concept of a field comprising a binary tree of pointers is well known to those of ordinary skill in the art.
- IL symbols 1140 and 1150 point to code objects 1220 and 1210 respectively and these IL symbols and code object pairs are now available in the persistent symbol table for use by the incremental imager of the present invention to form and run the program image thereby defined.
- a linker is invoked to take object code in the form of object files and resolve all the references between objects in the object code, and to produce a new, different image using the object files.
- This new image may represent an entire program (e.g., an executable file) or a self- contained portion of a program.
- Such a self-contained portion would have no unresolved external references and is often referred to as a dynamic link library, or DLL.
- the Incremental Imager performs some of these tasks normally performed by a linker.
- the Incremental Imager performs these tasks not on object files, but on the previously defined Code Objects.
- Object code elements are not necessarily placed in the same order or at the same address in the eventual image as they are in the original form. This is intuitively obvious in the case of object files, where addresses of function and data definitions (ex: code objects) are merely their position relative to the beginning of the file. Thus, there is no chance that a definition will ultimately occupy the same position in the executable file as it has in the object file. This is true even if the linker only needs one object file to produce the executable image, since the size of file header information is typically very different between the executable image and the object file.
- code objects are copied into runtime code objects by the Imager, and will most definitely not have the same address as the original Code Objects did.
- Code objects and Runtime Code Objects coexist in the same address space, and must therefore have different addresses.
- Runtime Code Objects which represent the translated program items in their relocated form.
- each Code Object T is located at address T a and its corresponding Runtime Code Object R is located in memory that is found at address R b by the Imager, and at address R c by the Runner.
- Addresses are normally used by software by the means of pointers (the term used in such programming languages as C, Pascal & C+ +), or references (used in such languages as Pascal and C+ +). Both forms simply retain the full, absolute address of an object. While hardware (e.g. : the computer's CPU) also uses addresses, it generally has more complex needs than does software. In order to simplify the logic of the transistors that implement a given hardware architecture, addresses utilized by hardware are formed by a myriad of different schemes, each of which depends on the hardware itself. By way of example, but not limitation, these hardware addresses may be split in two pieces, located in different instructions, or made relative to the address of the instruction that uses the address.
- the CPU i.e. the hardware, which needs to use addresses from category c when accessing data, but may often not be able to use them in the same form (pointers) as the Runner software is.
- the CPU is not interested in the address of the Runtime Code Object itself, but the address of the translated object code which is contained within it at some offset.
- the pu ⁇ ose of the process of code object traversal and relocation in this invention is to establish the necessary set of Runtime Code Objects, establish their addresses R b and R c , and make them available to consumers II and III (the Runner and the CPU), taking note of the fact that the CPU is really interested in / ⁇ .+&, where k is the constant (i.e.: the same for all runtime code objects) offset of the translated object code within the runtime code objects.
- a relocation record is a piece of data that describes what form an address must take at a given point in the program.
- the form varies not with the referenced address, but with the location where the reference occurs.
- data items that contain addresses of functions usually need to keep absolute pointers to the function, since the address will likely (but not certainly) be used by software.
- the CPU might use absolute addresses when using so-called branch-tables, or when calling to an address that was established dynamically (at runtime) by the program. This is referred to as an indirect reference, since the address referenced is contained in some piece of data that first has to be referenced.
- the hardware is also likely to use direct addresses when referring to data, but will normally use a more complex form when making a direct reference to functions from other functions. An example would be when implementing a subroutine call.
- the process of relocation is one of translating full addresses of Runtime Code Objects to whatever form is necessary at each point of reference.
- Runtime Code Objects only. However, the relocation records are attached to the Code Objects and not the Runtime Code Objects. This is logical, since relocation records are used in forming the complete Runtime Code Objects when building the image (either initially or incrementally).
- the Imager iterates over all Code Objects for which a corresponding Runtime Code Object has been created. For each Code Object T, it processes each relocation record L this way: 1. Note the type (form the address must take when used by the CPU) of relocation L.
- R b place a pointer to S c +k, where k is the constant offset of the translated object code within the runtime code object. If this pointer must be relative to the current location, use R e +0 L +k as the current location.
- the Imager/Debugger not only produces information for the hardware, it also produces information for the Runner. In that process, it need not worry about relocation forms and other complexities, since all the Imager/Debugger needs is to make sure to use addresses from category c whenever it communicates with the Runner. In some circumstances where space is of concern, and it is necessary to avoid duplication of information, the Runner will in fact accept addresses from category b, and itself translate them to category c.
- FIGS 13 through 17 illustrate a preferred embodiment of incremental image formation according to the principles of the present invention.
- An IL symbol previously stored in the persistent symbol table, is shown at 2000.
- Each IL symbol 2000 contains a definition field 2001 which comprises a code object pointer 2004 which points to a corresponding code object 2010 by means of direct memory addressing.
- Definition field 2001 is defined by IL instruction stream 1999.
- IL symbol 2000 further comprises a dependents field 2002 and an old definition field 2003.
- IL symbol 2000 further defines an IL name 2005. It is important to note that name 2005 is used only to display information to the programmer, e.g., in debug mode, and is defined during image creation.
- Each IL symbol 2000 is formed by the incremental builder of the present invention from part of the IL stream 1999.
- Code object pointer 2004 points to a code object 2010 corresponding to IL symbol 2000.
- Each code object 2010 contains a size field 2011, a relocations field 2012 and a code section, 2013.
- Code sections 2013 contain the previously discussed fully translated machine-language implementations of function definitions and the initial values of variables.
- Relocations field 2012 defines a relocations pointer 2014, which points to a relocations array 2020.
- Relocations array 2020 comprises a vector of relocation offsets and IL symbol references.
- the IL symbol to which relocations pointer 2014 points may be the same IL symbol which invoked the formation of code object 2010, as in the case of a recursive process, or in the more typical case, may point to a different IL symbol altogether.
- the update table is maintained by the Builder for the Imager, so that following editing or other changes to the source file, the Imager can locate the code objects which have changed. This ensures that Imager forms the image according to the newest code objects when updating the image.
- Each IL symbol 1000 causes the formation of a run-time code object 1010.
- additional IL symbols 1000 are added to the image.
- Each of these code objects contains a pointer to a relocations table 1020 as previously discussed, which points in turn to an IL symbol 1000, typically of finer granularity, which in turn points to its code object 1010 and so forth.
- a state of transitive closure is said to exist.
- Run time code objects are copies of code objects having additional scratchpad memory included in their structure, and with references changed to machine dependent forms during relocation. Before copies of the code objects are made, it is necessary to start the probe and the runner. The runtime loader starts prior to copying the code objects to the run-time code objects. This is because the utilization of shared memory requires that the two processes, i.e. the probe and the runner, must agree on memory to be allocated between the two processes. Each run-time code object contains references to two addresses, one for each process.
- the incremental imager 200 directs probe 300 to allocate memory. Probe 300 then directs runner 400 to allocate memory. It is important to recall that probe 300 and runner 400 are operating under two separate threads of execution in two distinct processes, and are logically separated by a process boundary 399. Responsive to the command to allocate memory, runner 400 allocates a machine address, e.g. 550, and returns this address across process boundary 399 to probe 300. Probe 300 passes the address to incremental imager
- the probe in a preferred embodiment of the present invention, is implemented according to the following pseudocode representation: while (true) do accept command from
- the runner in a preferred embodiment of the present invention is implemented according to the following pseudocode representation:
- ALLOCATE > allocate a block of shared memory
- Debugger 600 orders imager 200, at step 2, to build as previously discussed. For each code object (not shown), the imager 200 directs the probe 300 to allocate memory at step 4. Probe 300 orders runner 400 to allocate memory at step 5. Runner 400 allocates machine memory, and returns the address to probe 300. Probe 300 returns the address to the imager 200. This causes a request for the next code object to be issued. Steps 2 through 5 are repeated for each code object in the file. When the runner has completed allocating machine memory for the last code object, it informs probe 300 that it has finished allocating memory at 6. Responsively, probe 300 informs imager 200 at 7 that all memory has been allocated. The imager, at 8 informs the debugger at 8 that the build is complete. At this point, the image is completely formed in memory, and the program may be executed.
- debugger 600 orders probe 300 directly, at 9, to start the application. This order is transmitted in turn to runner
- the computer's operating system reports the failure to the debugger, along with the machine address of the failure and, optionally depending on the operating system, other information relating to the nature of the failure.
- the debugger translates the machine address to the code address, along with the other failure information, and informs the developer of the failure, its code address and the failure data.
- the developer uses this information to edit the source code file. Once the source file is edited, the developer instructs the debugger to resume program execution.
- the debugger directs the imager 200, at step 11 , to update the code objects affected by the editing as shown in Figure 17.
- IL symbol 901 caused the creation of code object 902 which in turn invoked the creation of runtime code object 903.
- runtime code object 903 is referred to by a second runtime code object 904.
- the pointer from IL symbol 901 which represents the function is reset from old code object
- New code object invokes the creation of a new code object 906.
- pointer 910 of old runtime code object 903 is reset from line 0 of its contained code to line 0 of the contained code of new runtime code object 906.
- data storage or transfer medium include but are not necessarily limited to: magnetic media including magnetic disks, tapes, hard drives and the like; electronic memory devices including RAM, flash memory and the like; mechanical data storage materials including punch tape and Hollerith cards; and optical media including CD-ROM, "floptical” drives and the like.
- the principles of the present invention specifically contemplate the transfer thereof over any media including telephone lines or other electronic networks to include local and wide area nets, including but not limited to the Internet.
- the principles of the present invention further specifically contemplate such implementation for the storage, use, transfer, sale, lease, rental or any and all other usages thereof.
- the present invention has been particularly shown and described with respect to certain preferred embodiments of features thereof. However, it should be readily apparent to those of ordinary skill in the art that various changes and modifications in form and detail may be made without departing from the spirit and scope of the invention as set forth in the appended claims. The invention disclosed herein may be practiced without any element which is not specifically disclosed herein.
Abstract
Description
Claims
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP9530969A JP2000507373A (en) | 1996-02-29 | 1997-02-26 | Interactive software development system |
AU19568/97A AU1956897A (en) | 1996-02-29 | 1997-02-26 | Interactive software development system |
EP97907605A EP0883844A1 (en) | 1996-02-29 | 1997-02-26 | Interactive software development system |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/608,820 US5764989A (en) | 1996-02-29 | 1996-02-29 | Interactive software development system |
US08/608,820 | 1996-02-29 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO1997032250A1 true WO1997032250A1 (en) | 1997-09-04 |
Family
ID=24438154
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US1997/002177 WO1997032250A1 (en) | 1996-02-29 | 1997-02-26 | Interactive software development system |
Country Status (6)
Country | Link |
---|---|
US (1) | US5764989A (en) |
EP (1) | EP0883844A1 (en) |
JP (1) | JP2000507373A (en) |
AU (1) | AU1956897A (en) |
CA (1) | CA2248181A1 (en) |
WO (1) | WO1997032250A1 (en) |
Families Citing this family (73)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2795244B2 (en) * | 1996-01-17 | 1998-09-10 | 日本電気株式会社 | Program debugging system |
GB2312973B (en) * | 1996-05-08 | 2000-05-03 | Ibm | Programming aid |
US5991535A (en) | 1996-07-03 | 1999-11-23 | Sun Microsystems, Inc. | Visual composition tool for constructing application programs using distributed objects on a distributed object network |
EP0932865B1 (en) * | 1996-10-25 | 2002-08-14 | SCHLUMBERGER Systèmes | Using a high level programming language with a microcontroller |
US5937191A (en) * | 1997-06-03 | 1999-08-10 | Ncr Corporation | Determining and reporting data accessing activity of a program |
US5901315A (en) * | 1997-06-13 | 1999-05-04 | International Business Machines Corporation | Method for debugging a Java application having native method dynamic load libraries |
CA2211505C (en) * | 1997-07-25 | 2002-02-05 | Ibm Canada Limited-Ibm Canada Limitee | Setting instance breakpoints in object oriented computer programs |
US7434172B1 (en) * | 1997-10-21 | 2008-10-07 | International Business Machines Corporation | Color and symbol coded visual cues for relating screen items to each other |
US5953526A (en) * | 1997-11-10 | 1999-09-14 | Internatinal Business Machines Corp. | Object oriented programming system with displayable natural language documentation through dual translation of program source code |
US5995975A (en) * | 1997-11-25 | 1999-11-30 | International Business Machines Corporation | Dictionary based process for object containment |
US6230318B1 (en) * | 1998-02-24 | 2001-05-08 | Microsoft Corporation | Application programs constructed entirely from autonomous component objects |
US6704927B1 (en) * | 1998-03-24 | 2004-03-09 | Sun Microsystems, Inc. | Static binding of dynamically-dispatched calls in the presence of dynamic linking and loading |
US6113645A (en) * | 1998-04-22 | 2000-09-05 | Scientific Learning Corp. | Simulated play of interactive multimedia applications for error detection |
US6681280B1 (en) | 1998-10-29 | 2004-01-20 | Fujitsu Limited | Interrupt control apparatus and method separately holding respective operation information of a processor preceding a normal or a break interrupt |
GB9825102D0 (en) | 1998-11-16 | 1999-01-13 | Insignia Solutions Plc | Computer system |
US6637020B1 (en) * | 1998-12-03 | 2003-10-21 | International Business Machines Corporation | Creating applications within data processing systems by combining program components dynamically |
US7526468B2 (en) * | 1999-01-08 | 2009-04-28 | Computer Associates Think, Inc. | System and method for recursive path analysis of DBMS procedures |
US6446257B1 (en) * | 1999-02-04 | 2002-09-03 | Hewlett-Packard Company | Method and apparatus for pre-allocation of system resources to facilitate garbage collection |
US6357021B1 (en) * | 1999-04-14 | 2002-03-12 | Mitsumi Electric Co., Ltd. | Method and apparatus for updating firmware |
JP4118456B2 (en) * | 1999-06-29 | 2008-07-16 | 株式会社東芝 | Program language processing system, code optimization method, and machine-readable storage medium |
US7152228B2 (en) | 1999-07-08 | 2006-12-19 | Science Applications International Corporation | Automatically generated objects within extensible object frameworks and links to enterprise resources |
US6970844B1 (en) | 1999-08-27 | 2005-11-29 | Computer Sciences Corporation | Flow designer for establishing and maintaining assignment and strategy process maps |
US6961708B1 (en) | 1999-08-27 | 2005-11-01 | Computer Sciences Corporation | External interface for requesting data from remote systems in a generic fashion |
GB9921720D0 (en) * | 1999-09-14 | 1999-11-17 | Tao Group Ltd | Loading object-oriented computer programs |
US6463578B1 (en) * | 1999-11-23 | 2002-10-08 | International Business Machines Corporation | Systems, methods and computer program products for debugging java server page files using compiled java class file modifications |
US6757893B1 (en) | 1999-12-17 | 2004-06-29 | Canon Kabushiki Kaisha | Version control system for software code |
US6986128B2 (en) * | 2000-01-07 | 2006-01-10 | Sony Computer Entertainment Inc. | Multiple stage program recompiler and method |
GB0004090D0 (en) * | 2000-02-22 | 2000-04-12 | Innovation Venture Ltd | Application programming system and method of operation thereof |
US6728951B1 (en) * | 2000-04-14 | 2004-04-27 | Hewlett-Packard Development Company, L.P. | System and method for performing automated incremental compilation of computer programs |
US6915509B1 (en) * | 2000-06-28 | 2005-07-05 | Microsoft Corporation | Method and system for debugging a program |
US6941353B1 (en) * | 2000-06-29 | 2005-09-06 | Auran Holdings Pty Ltd | E-commerce system and method relating to program objects |
AU2002226901A1 (en) * | 2000-11-17 | 2002-05-27 | Proceler, Inc. | An instruction set architecture to aid code generation for hardware platforms multiple heterogeneous functional units |
US20030023950A1 (en) * | 2001-01-10 | 2003-01-30 | Wei Ma | Methods and apparatus for deep embedded software development |
US7360205B2 (en) * | 2001-02-09 | 2008-04-15 | International Business Machines Corporation | Minimizing interaction costs among components of computer programs |
US20030177140A1 (en) * | 2001-02-28 | 2003-09-18 | Answer Financial, Inc. | Method for developing application programs using program constructs |
US7426717B1 (en) * | 2001-11-27 | 2008-09-16 | Adobe Systems Incorporated | System and method for debugging files in a runtime environment |
US6976254B2 (en) * | 2001-11-28 | 2005-12-13 | Esmertec Ag | Inter-method control transfer for execution engines with memory constraints |
US7281242B2 (en) * | 2002-01-18 | 2007-10-09 | Bea Systems, Inc. | Flexible and extensible Java bytecode instrumentation system |
US8769517B2 (en) * | 2002-03-15 | 2014-07-01 | International Business Machines Corporation | Generating a common symbol table for symbols of independent applications |
US7174547B2 (en) * | 2002-03-25 | 2007-02-06 | Ciena Corporation | Method for updating and restoring operating software in an active region of a network element |
US7844734B2 (en) * | 2002-11-18 | 2010-11-30 | Innopath Software, Inc. | Dynamic addressing (DA) using a centralized DA manager |
EP1465069B1 (en) * | 2003-04-01 | 2017-01-25 | Sap Se | Method and computer system for activation of source files |
US20050038832A1 (en) * | 2003-08-14 | 2005-02-17 | International Business Machines Corporation | Application error recovery using solution database |
US7383539B2 (en) | 2003-09-18 | 2008-06-03 | International Business Machines Corporation | Managing breakpoints in a multi-threaded environment |
US7150006B2 (en) * | 2003-11-03 | 2006-12-12 | Microsoft Corporation | Techniques for managed code debugging |
US7437712B1 (en) * | 2004-01-22 | 2008-10-14 | Sprint Communications Company L.P. | Software build tool with revised code version based on description of revisions and authorizing build based on change report that has been approved |
US7523277B1 (en) * | 2005-03-30 | 2009-04-21 | Symantec Operating Corporation | Transient point-in-time images for continuous data protection |
US8407206B2 (en) * | 2005-05-16 | 2013-03-26 | Microsoft Corporation | Storing results related to requests for software development services |
US7770152B1 (en) * | 2005-05-20 | 2010-08-03 | Oracle America, Inc. | Method and apparatus for coordinating state and execution context of interpreted languages |
US7644396B2 (en) * | 2005-11-29 | 2010-01-05 | Microsoft Corporation | Optimal program execution replay and breakpoints |
US20070168975A1 (en) * | 2005-12-13 | 2007-07-19 | Thomas Kessler | Debugger and test tool |
US8458661B2 (en) | 2006-03-31 | 2013-06-04 | Ebay Inc. | Distributed parallel build system |
US20080209401A1 (en) * | 2007-02-22 | 2008-08-28 | Microsoft Corporation | Techniques for integrating debugging with decompilation |
TWI416410B (en) * | 2008-04-11 | 2013-11-21 | Hon Hai Prec Ind Co Ltd | System and method for updating version of the executable file |
US8266597B2 (en) * | 2008-06-16 | 2012-09-11 | International Business Machines Corporation | Dynamically patching computer code using breakpoints |
US8874928B2 (en) * | 2008-10-31 | 2014-10-28 | Apple Inc. | System and method for obfuscating constants in a computer program |
US8276021B2 (en) * | 2009-12-18 | 2012-09-25 | Microsoft Corporation | Concurrency test effectiveness via mutation testing and dynamic lock elision |
US20110202384A1 (en) * | 2010-02-17 | 2011-08-18 | Rabstejnek Wayne S | Enterprise Rendering Platform |
US20110271257A1 (en) * | 2010-04-29 | 2011-11-03 | International Business Machines Corporation | Defect management in integrated development environments |
US8997049B1 (en) | 2010-05-21 | 2015-03-31 | Cadence Design Systems, Inc. | Method and system for debugging of compiled code using an interpreter |
US8856724B2 (en) * | 2011-06-20 | 2014-10-07 | Ebay Inc. | Systems and methods for incremental software development |
US8898628B2 (en) | 2011-09-23 | 2014-11-25 | Ahmad RAZA | Method and an apparatus for developing software |
US9529575B2 (en) | 2012-02-16 | 2016-12-27 | Microsoft Technology Licensing, Llc | Rasterization of compute shaders |
US8863099B2 (en) * | 2012-11-05 | 2014-10-14 | International Business Machines Corporation | Compilation and placement of instructions in a memory system |
US8914778B2 (en) | 2012-11-05 | 2014-12-16 | International Business Machines Corporation | Data placement for execution of an executable |
US9134962B1 (en) | 2013-03-15 | 2015-09-15 | Sanctum Solutions, Inc. | Interactive content development |
US9262300B1 (en) * | 2014-06-24 | 2016-02-16 | Google Inc. | Debugging computer programming code in a cloud debugger environment |
US10169192B2 (en) * | 2015-11-11 | 2019-01-01 | International Business Machines Corporation | Automatic collection and presentation of runtime data semantics |
US9760349B1 (en) * | 2016-11-09 | 2017-09-12 | Red Hat, Inc. | Managing different software dependencies associated with source code |
WO2018100633A1 (en) * | 2016-11-29 | 2018-06-07 | 三菱電機株式会社 | Control device and program update method |
US10762211B2 (en) * | 2018-04-12 | 2020-09-01 | United States Of America, As Represented By The Secretary Of The Navy | Source code diagnostic instrument |
US11263308B2 (en) | 2019-03-25 | 2022-03-01 | Micron Technology, Inc. | Run-time code execution validation |
US11275580B2 (en) * | 2020-08-12 | 2022-03-15 | Servicenow, Inc. | Representing source code as implicit configuration items |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4802165A (en) * | 1986-10-08 | 1989-01-31 | Enteleki, Inc. | Method and apparatus of debugging computer programs |
US5247651A (en) * | 1990-04-17 | 1993-09-21 | At&T Bell Laboratories | Interactive computer program specification and simulation system |
US5581696A (en) * | 1995-05-09 | 1996-12-03 | Parasoft Corporation | Method using a computer for automatically instrumenting a computer program for dynamic debugging |
Family Cites Families (34)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4589068A (en) * | 1983-10-03 | 1986-05-13 | Digital Equipment Corporation | Segmented debugger |
US4809170A (en) * | 1987-04-22 | 1989-02-28 | Apollo Computer, Inc. | Computer device for aiding in the development of software system |
US4953084A (en) * | 1987-11-16 | 1990-08-28 | Hewlett-Packard Company | Method and apparatus using variable ranges to support symbolic debugging of optimized code |
AU638999B2 (en) * | 1989-06-30 | 1993-07-15 | Digital Equipment Corporation | Incremental compiler for source-code development system |
US5182806A (en) * | 1989-06-30 | 1993-01-26 | Digital Equipment Corporation | Incremental compiler for source-code development system |
US5325531A (en) * | 1989-06-30 | 1994-06-28 | Digital Equipment Corporation | Compiler using clean lines table with entries indicating unchanged text lines for incrementally compiling only changed source text lines |
US5170465A (en) * | 1989-06-30 | 1992-12-08 | Digital Equipment Corporation | Incremental-scanning compiler for source-code development system |
US5193191A (en) * | 1989-06-30 | 1993-03-09 | Digital Equipment Corporation | Incremental linking in source-code development system |
US5201050A (en) * | 1989-06-30 | 1993-04-06 | Digital Equipment Corporation | Line-skip compiler for source-code development system |
EP0423989A3 (en) * | 1989-10-16 | 1992-09-23 | Hewlett-Packard Company | Software compiler and linker with improved line number table |
US5204960A (en) * | 1990-01-08 | 1993-04-20 | Microsoft Corporation | Incremental compiler |
US5175856A (en) * | 1990-06-11 | 1992-12-29 | Supercomputer Systems Limited Partnership | Computer with integrated hierarchical representation (ihr) of program wherein ihr file is available for debugging and optimizing during target execution |
US5560009A (en) * | 1990-09-21 | 1996-09-24 | Hewlett-Packard Company | Generating symbolic debug information by merging translation and compiler debug information |
US5459868A (en) * | 1990-11-30 | 1995-10-17 | St Computer Systems & Services | Interpretive object-oriented facility which can access pre-compiled classes |
US5307499A (en) * | 1990-11-30 | 1994-04-26 | Singapore Computer Systems Limited | Interpretive object-oriented facility which can access pre-compiled classes |
US5291583A (en) * | 1990-12-14 | 1994-03-01 | Racal-Datacom, Inc. | Automatic storage of persistent ASN.1 objects in a relational schema |
US5432795A (en) * | 1991-03-07 | 1995-07-11 | Digital Equipment Corporation | System for reporting errors of a translated program and using a boundry instruction bitmap to determine the corresponding instruction address in a source program |
US5265254A (en) * | 1991-08-14 | 1993-11-23 | Hewlett-Packard Company | System of debugging software through use of code markers inserted into spaces in the source code during and after compilation |
US5355494A (en) * | 1991-12-12 | 1994-10-11 | Thinking Machines Corporation | Compiler for performing incremental live variable analysis for data-parallel programs |
CA2061298C (en) * | 1992-02-17 | 1996-12-03 | Douglas J. Mortson | Method for detecting critical failures during the building of complex computer programs from source code parts |
US5357628A (en) * | 1992-03-25 | 1994-10-18 | Intel Corporation | Computer system having integrated source level debugging functions that provide hardware information using transparent system interrupt |
JPH06103048A (en) * | 1992-04-24 | 1994-04-15 | Nec Corp | Program development supporting system |
US5327562A (en) * | 1992-05-06 | 1994-07-05 | Microsoft Corporation | Method for implementing virtual function tables in a compiler for an object-oriented programming language |
US5371747A (en) * | 1992-06-05 | 1994-12-06 | Convex Computer Corporation | Debugger program which includes correlation of computer program source code with optimized object code |
WO1993025964A1 (en) * | 1992-06-05 | 1993-12-23 | Convex Computer Corporation | Computer program debugging in the presence of compiler synthesized variables |
JPH0683597A (en) * | 1992-09-02 | 1994-03-25 | Matsushita Electric Ind Co Ltd | Object oriented program development device and object oriented program development method |
US5404525A (en) * | 1992-09-30 | 1995-04-04 | International Business Machines Corporation | Efficient method router that supports multiple simultaneous object versions |
US5339433A (en) * | 1992-11-19 | 1994-08-16 | Borland International, Inc. | Symbol browsing in an object-oriented development system |
JPH06161726A (en) * | 1992-11-20 | 1994-06-10 | Toshiba Corp | Tool data reusing device |
FR2701580B1 (en) * | 1993-02-10 | 1995-03-24 | Bull Sa | Method of administration of applications with standard protocols. |
JP3178151B2 (en) * | 1993-03-19 | 2001-06-18 | 富士ゼロックス株式会社 | Message Oriented Message Compiling Device |
US5561800A (en) * | 1993-05-19 | 1996-10-01 | Hewlett-Packard Company | Method and apparatus for incrementally linking modified routines into software |
US5758160A (en) * | 1993-06-28 | 1998-05-26 | Object Technology Licensing Corporation | Method and apparatus for building a software program using dependencies derived from software component interfaces |
US5519866A (en) * | 1993-06-28 | 1996-05-21 | Taligent, Inc. | Method and apparatus of incrementally linking components of a modeled computer program |
-
1996
- 1996-02-29 US US08/608,820 patent/US5764989A/en not_active Expired - Lifetime
-
1997
- 1997-02-26 JP JP9530969A patent/JP2000507373A/en active Pending
- 1997-02-26 WO PCT/US1997/002177 patent/WO1997032250A1/en not_active Application Discontinuation
- 1997-02-26 AU AU19568/97A patent/AU1956897A/en not_active Abandoned
- 1997-02-26 EP EP97907605A patent/EP0883844A1/en not_active Withdrawn
- 1997-02-26 CA CA002248181A patent/CA2248181A1/en not_active Abandoned
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4802165A (en) * | 1986-10-08 | 1989-01-31 | Enteleki, Inc. | Method and apparatus of debugging computer programs |
US5247651A (en) * | 1990-04-17 | 1993-09-21 | At&T Bell Laboratories | Interactive computer program specification and simulation system |
US5581696A (en) * | 1995-05-09 | 1996-12-03 | Parasoft Corporation | Method using a computer for automatically instrumenting a computer program for dynamic debugging |
Also Published As
Publication number | Publication date |
---|---|
EP0883844A1 (en) | 1998-12-16 |
US5764989A (en) | 1998-06-09 |
CA2248181A1 (en) | 1997-09-04 |
JP2000507373A (en) | 2000-06-13 |
AU1956897A (en) | 1997-09-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US5764989A (en) | Interactive software development system | |
US5848274A (en) | Incremental byte code compilation system | |
US5313387A (en) | Re-execution of edit-compile-run cycles for changed lines of source code, with storage of associated data in buffers | |
US5325531A (en) | Compiler using clean lines table with entries indicating unchanged text lines for incrementally compiling only changed source text lines | |
US5170465A (en) | Incremental-scanning compiler for source-code development system | |
US5182806A (en) | Incremental compiler for source-code development system | |
US5201050A (en) | Line-skip compiler for source-code development system | |
US6067641A (en) | Demand-based generation of symbolic information | |
US5193191A (en) | Incremental linking in source-code development system | |
US7992141B2 (en) | Method and apparatus for building executable computer programs using compiled program libraries | |
US6795963B1 (en) | Method and system for optimizing systems with enhanced debugging information | |
US5680622A (en) | System and methods for quickly detecting shareability of symbol and type information in header files | |
Somogyi et al. | Mercury, an efficient purely declarative logic programming language | |
US5850554A (en) | Compiler tool set for efficiently generating and easily managing multiple program versions of different types | |
US7263689B1 (en) | Application program interface for dynamic instrumentation of a heterogeneous program in a distributed environment | |
US20060200806A1 (en) | Apparatus, system, and method for trace insertion | |
US20060212847A1 (en) | Type checker for a typed intermediate representation of object-oriented languages | |
US20090319554A1 (en) | Unified metadata for external components | |
US20090320007A1 (en) | Local metadata for external components | |
US20060212861A1 (en) | Typed intermediate representation for object-oriented languages | |
US5301327A (en) | Virtual memory management for source-code development system | |
Niephaus et al. | Graalsqueak: toward a smalltalk-based tooling platform for polyglot programming | |
AU638999B2 (en) | Incremental compiler for source-code development system | |
Atkinson et al. | Experiences creating a portable Cedar | |
Tolmach | Debugging standard ML |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A1 Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE HU IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK TJ TM TR TT UA UG UZ VN AM AZ BY KG KZ MD RU TJ TM |
|
AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): GH KE LS MW SD SZ UG AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
ENP | Entry into the national phase |
Ref document number: 2248181 Country of ref document: CA Ref document number: 2248181 Country of ref document: CA Kind code of ref document: A |
|
WWE | Wipo information: entry into national phase |
Ref document number: 1997907605 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 97193981.0 Country of ref document: CN |
|
WWP | Wipo information: published in national office |
Ref document number: 1997907605 Country of ref document: EP |
|
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
WWW | Wipo information: withdrawn in national office |
Ref document number: 1997907605 Country of ref document: EP |