CA2111958C - Method and apparatus for modifying relocatable object code files and monitoring programs - Google Patents
Method and apparatus for modifying relocatable object code files and monitoring programs Download PDFInfo
- Publication number
- CA2111958C CA2111958C CA002111958A CA2111958A CA2111958C CA 2111958 C CA2111958 C CA 2111958C CA 002111958 A CA002111958 A CA 002111958A CA 2111958 A CA2111958 A CA 2111958A CA 2111958 C CA2111958 C CA 2111958C
- Authority
- CA
- Canada
- Prior art keywords
- memory
- preexisting
- instructions
- new
- code
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims description 66
- 238000012544 monitoring process Methods 0.000 title claims description 43
- 230000006870 function Effects 0.000 claims description 47
- 238000004590 computer program Methods 0.000 claims description 29
- 238000012423 maintenance Methods 0.000 claims description 17
- 238000003860 storage Methods 0.000 claims description 13
- 230000011664 signaling Effects 0.000 claims description 9
- 238000012546 transfer Methods 0.000 claims description 9
- 238000004519 manufacturing process Methods 0.000 claims description 4
- 230000003190 augmentative effect Effects 0.000 claims description 2
- 229940036310 program Drugs 0.000 abstract 1
- 230000011514 reflex Effects 0.000 abstract 1
- 230000008569 process Effects 0.000 description 12
- 238000003491 array Methods 0.000 description 9
- 238000013459 approach Methods 0.000 description 6
- 230000008859 change Effects 0.000 description 6
- 238000003780 insertion Methods 0.000 description 5
- 230000037431 insertion Effects 0.000 description 5
- 230000015572 biosynthetic process Effects 0.000 description 4
- 238000011161 development Methods 0.000 description 4
- 238000004458 analytical method Methods 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000001514 detection method Methods 0.000 description 2
- 238000012966 insertion method Methods 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- BBRBUTFBTUFFBU-LHACABTQSA-N Ornoprostil Chemical compound CCCC[C@H](C)C[C@H](O)\C=C\[C@H]1[C@H](O)CC(=O)[C@@H]1CC(=O)CCCCC(=O)OC BBRBUTFBTUFFBU-LHACABTQSA-N 0.000 description 1
- 101150105133 RRAD gene Proteins 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 230000002401 inhibitory effect Effects 0.000 description 1
- 229940004975 interceptor Drugs 0.000 description 1
- 230000001343 mnemonic effect Effects 0.000 description 1
- 239000002674 ointment Substances 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 230000001131 transforming effect Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
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/362—Software debugging
- G06F11/3636—Software debugging by tracing the execution of the program
-
- 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/362—Software debugging
- G06F11/3624—Software debugging by performing operations on the source code, e.g. via a compiler
-
- 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/362—Software debugging
- G06F11/3644—Software debugging by instrumenting at runtime
-
- 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/44—Encoding
- G06F8/447—Target code generation
-
- 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/54—Link editing before load time
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Debugging And Monitoring (AREA)
- Stored Programmes (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Devices For Executing Special Programs (AREA)
Abstract
An object code expansion program (5) inserts new instructions and data between preexisting instructions end data of en object code file (I); offsets are modified to reflex new positions of the preexisting instructions and data. For each item of preexisting object code (instruct-tion or data), the following steps are performed: making a new code block comprising any desired new instructions and the item, and storing it as new object code; tracking the location of the item and the new code block within the new object code; and tracking items that contain inter-item offset. Then, each inter-item offset is updated using the new location of the item or new code block, as re-quired. Finally, offsets in symbol tables and relocation structures are updated with the new location of the item.
This extension program is used to add instructions to ob-ject code files to monitor memory accesses of another pro-gram.
This extension program is used to add instructions to ob-ject code files to monitor memory accesses of another pro-gram.
Description
WO 93/00633 21119 5 8~ ~ ' : PCT/US92/04672 METHOD AND APPARATUS FOR H~ODIFYING RELOCATABLE
OBJECT CODE FILES AND MONI'~'QRING PROG$AMS
BACKGROUND OF THE INVENTION
The present invention relates generally to a method and apparatus for modifying relocatable object files. In particular, the present invention relates to a method far inserting additional instructions and data into an existing relocatable object file of a computer program, for any purpose.
Most particularly, this purpose is to monitor memory access by 15y the computer program.
Despite the recent increase in CPU speeds and software complexity, most programmers continue to rely on development tools that were designed over fifteen years ago and that have not changed significantly since then. These development tools have serious inadequacies that exacerbate the difficulties of developing large, complex programs.
Problems with developing applications in C/C++ are often more serious than with other programming languages, but are fairl~r typical. C/C++~s pointer and memory management facilities make it difficult to build large, robust programs.
Prudent C/C++ programmers currently hesitate to use many com~arcial object~code libraries because they are worried they may lose weeks of time later on in tracking down wild-pointer bugs introduced by their particular use of a given library.
..
The difficulty in tracking down these kinds of programming bugs and many others is directly tied to the manner in which exaoutabla'code is created from souroe node and to the inadequaoies of current development tools.
The prooess o! transforming source node into "executable" code is, briefly, as follows. The source code for a typical computer program is divided into many files. Some of these files may contain high-level language code, such as C, C++, Pascal, Fortran, Ada, or PL1, and some may contain assembly language code. Each high-level language file is WO 93/00633 21119 ~ ~ f . , PCT/US92/04672 translated by a language-specific compiler into either a relocatable object file, or into an assembly language file. An assembler translates the assembly language files into relocatable object files. A linker merges all of the relocatable object files into a single executable program.
As programs get larger and more complex, they become more difficult to test and debug. If one wants to monitor or analyze aspects of a program's behavior, the current practice is to have the compiler output the extra instructions required to implement the desired monitoring. One example of this exists in many Pascal compilers; there is typically a way to request the compiler to output the extra instructions required to check array bounds at run time, and to signal an error if there is a violation. Another example exists in many vnix/C
compilers; most compilers will, upon request, output extra instructions to r~cord how many times each function was called.
The approach of having the compiler output the extra instructions required to implement a monitoring or analysis scheme is, however, flawed in at least three significant ways:
First, modifying the compiler to output new sequences is difficult, and in practice, nearly impossible, because most programmers don't have the source code to the compiler.
Second, recompiling all of a program's files just to get the extra instructions inserted can be very time consuming and wasteful. Finally, not all code goes through a compiler;' some is'written in assembly language and does not get the new instructions inserted into it. Thus, any monitoring which requires co~~yte coverage to work correctly cannot be implemented through only the compiler.
Some of the most vicious development problems relate to the diffioulty in finding and eliminating a large class of memory-aooea~ related errors. Among the most important memory-acoess related errors that a programmer needs to detect are array bounds violations, uninitialiaed memory reads, free memory access, and data changing strangely.
Array bounds violations (where an array is any collection of data contiguous in memory) occur on those 3 211 ~ ~ ~ g ~ ' ' ~ . PCT/US92/04672 occasions when a program reads or writes past the end, or before the beginning, of an array and accesses whatever datum happens to be in that memory location.
Uninitialized memory reads happen when a program allocates some memory for data storage, but fails to initialize it completely. Later, an uninitialized portion is read, unintentionally providing a random value, which might sometimes cause to the program to fail, and sometimes not.
Free memory access describes the situation where a program deallocates some memory but incorrectly continues to use it. If the program reallocates that memory for another purpose, then it will be using the same memory for two different purposes, and the program will probably perform incorrectly.
"Data changing strangely" is a bit of a catch-all expression. Often there are many ways to change a datum, especially~a "global" datum. The programmer can have a difficult time discovering which function is changing the datum incorrectly, in a given run of the program. What the programmer needs is to have a monitoring program tell him or her whenever a specified datum changes (this is called a watchpoint):
A comprehensive way to monitor the execution of today's and tomorrow's programs, in particular their memory access, is clearly needed by the program developer.
SUMMARY. OF THE INVENTION
~rccording to one aspect of the invention, an object code file ~is'expanded by inserting additional instructions and/or data between preexisting instructions and data, which may also be modified in some ways. A basically unlimited variety of additional instructions and data can be ins~rted for an equally wide variety of purposes. After the insertion step, the offsets in the file are checked and modified, if necessary, to reflect the new positions of the preexisting instructions and data, so that the expanded code will execute properly. in the preferred embodiment additional offsets in symbol tables, data relocation tables and instruction relocation tables are i n updated in the same general manner as the other of f sets .
The basic method is as follows:
An old object code table is formed in memory space, containing the preexisting instructions and data.
Space is also allocated for other tables: a new object code table, an inter-item offset table. For each item in the old object code table (whether instruction or datum), the following four steps are performed: (1) making a new code block comprising any desired additional instructions and/or data and the item, and storing it into the new object code table; (2) storing the location of the item within the new object code table into the forward index table; (3) storing the location of the new code block within the new object code table into the forward control index table; and (4) for items that contain inter-item offsets, storing the location within the old object code table, of the offset and the base from which it is measured, into the inter-item offset table. Then, for each pair of offset/base locations in the inter-item offset table, the offset stored in the new object code table is updated using the index tables. Finally, the offsets in any symbol tables, instruction relocation structures, or data relocation structures in the old object code file are updated so that the new offset refers to the location in the obj ect code table to where the item referred to was moved.
Accordingly, the present invention provides A method for inserting new instructions into a computer program between preexisting instructions, said method comprising the steps of:
a) providing an old object code table containing the preexisting instructions;
i b) providing a new object code table, an inter-item offset table, a forward index table, and a 5 forward control index table, said tables being for storing items in, said items having locations within said tables;
c) performing the following steps for each preexisting instruction in the old object code table:
i) storing a new code block into the new object code table, said new code block comprising any desired new instructions and the preexisting instruction;
ii) storing the location of the preexisting instruction within the new object code table into the forward index table;
iii) storing the location of the new code block within the new object code table into the forward control index table; and iv) for preexisting instructions which contain an inter-item offset, indicating the offset in the inter-item offset table; and d) for each inter-item offset indicated in the inter-item offset table, updating the inter-item offset, using the forward control index table for inter item offsets which are for program control transfer, and using the forward index table otherwise.
The present invention also provides method for inserting new instructions into a relocatable object file having preexisting instructions, data, and linking and debugging auxiliary structures having at least some offsets associated with the preexisting instructions and data, said method comprising the steps of i 5a a) providing an old object code table, a new object code table, an inter-item offset table, a forward index table, and a forward control index table, said tables being for storing items in, said items having locations within said tables;
b) copying the preexisting instructions and data of the object file into the old object code table;
c) performing the following steps for each item in the old object code table;
i) storing a new code block into the new object code table, said new code block comprising any desired new instructions and the item;
ii) storing the location of the item within the new object code table into the forward index table;
iii) storing the location of the new code block within the new object code table into the forward control index table; and iv) for items which contain an inter-item offset pointing to a target and referenced from a base, indicating in the inter-item offset table the locations of the target and base within the old object code table and of the offset in the new object code table, and modifying the item, if necessary, to be consistent with a maximum-byte offset;
d) for each inter-item offset indicated in the inter-item offset table, determining a forward location for the base using the forward index table, determining a forward location for the target using the forward control index table for targets which are program control transfer destinations and using the forward index table otherwise, and updating the inter-item offset in the new i i 5b object code table using the forward locations of the base and target;
e) updating the offsets in the auxiliary structures; and f) creating a new relocatable object file comprising the new object code table and the updated auxiliary structure.
The present invention also provides a method for inserting new instructions into a relocatable object file having preexisting instructions, data, and auxiliary structure, said auxiliary structures having at least some offsets and comprising text relocation structures, data relocation structures, and symbol structures, said method comprising the steps of:
a) providing an entry point table, a new object code table, an inter-item offset table, a forward index table, and a forward control index table, said tables being for storing items in, said items having locations within said tables;
b) providing an old object code table containing the preexisting instructions and data of the object file;
c) for each symbol structure associated with a function and having a function entry address, storing the function entry address in the entry point table, said entry address indicating in the old object code table a first instruction of the function, the function also having a last instruction, all items between the first instruction and last instruction also being instructions of the function;
d) performing the following steps for each i 5c entry address stored in the entry point table:
i) performing the following steps for each preexisting instruction of the function indicated by the entry address:
1) storing a new code block into the new object code table, said new code block comprising any desired new instructions and the preexisting instruction;
2) storing the location of the preexisting instruction within the new object code table into the forward index table;
3) storing the location of the new code block within the new object code table into the forward control index table; and 4) for preexisting instructions that contain an inter-item offset pointing to a target and referenced from a base, indicating in the inter-item offset table the locations of the target and base within the old object code table and of the offset in the new object code table, and modifying the preexisting instructions in the new code block, if necessary, to be consistent with a maximum-byte offset; and ii) performing the following steps for each item in the old object code table after the last preexisting instruction of the function indicated by the entry address and before a closest next entry address:
1) copying the item into the new object code table;
2) storing the location of the item within the new object code table into the forward index table;
i .;
5d e) for each inter-item offset indicated in the inter-item offset table, determining a forward location for the base using the forward index table, determining a forward location for the target using the forward control index table for targets which are program control transfer destinations and using the forward index table otherwise, and updating the inter-item offset in the new object code table using the forward locations of the base and target;
f) updating offsets in the auxiliary structures; and g) creating a new relocatable object file comprising the new object code table and the updated auxiliary structures.
According to a second aspect of the invention, all or substantially all the memory accesses of a given program are monitored (not including the memory accesses fox instruction fetch), for the purposes of performing error-checking. In one embodiment, all the object code files for an executable program are processed, and instructions are added to implement the following monitoring scheme. A memory status array is established, with an entry for most memory locations that are validly accessible by the program. Each entry indicates the state of the corresponding memory location, and the state can be one of the following three: unallocated and uninitialized, allocated but uninitialized, and allocated and initialized. Before each preexisting instruction which accesses memory or which can change memory status, extra instructions are added to maintain the memory status array, and to use the memory status array to check i n 5e for the errors of writing to unallocated memory and reading from unallocated or uninitialized memory. In one particular embodiment, the data sections of the object code files are expanded with extra dummy entries between each datum. These extra entries are assigned the status of unallocated and uninitialized, and aid in the detection of array bounds violations and similar data errors. In another particular embodiment, a list is stored of memory or datum locations which are to be watchpoints with which more comprehensive monitoring is to be performed.
Accordingly, the present invention provides a method of modifying a computer program to have the ability to monitor most of its own memory accesses, said computer program having preexisting code items, said method comprising the steps of a) for most preexisting code items the performance of which involves a memory read, adding memory read monitoring code located so that it will be executed each time the memory read preexisting code item is executed; and b) for most preexisting code items the performance of which involves a memory write, adding memory write monitoring code located so that it will be executed each time the memory write preexisting code item is executed.
The present invention also provides a computer implemented method for producing a set of modified machine instrucdtions from a set of preexisting machine instructions, said set of modified machine instructions having the ability to maintain memory status i 5f information for a region of memory and having the ability to check memory accesses to said region of memory, said set of preexisting machine instructions corresponding to a set of preexisting memory accesses to region of memory, said memory status information indicating at least two memory states, said at least two memory states including an allocated state and an unallocated state, said allocated state corresponding to a memory location allocated by a computer program, and said unallocated state corresponding to a memory location not allocated by said computer program, said method comprising the steps of providing in a computer storage medium, status information maintenance machine instructions, wherein at least a first portion of said status information maintenance machine instructions is for being executed in conjunction with memory allocation code, and for updating to said allocation state said status information for memory allocated within said memory region by said memory allocation code, and at least a second portion of said status information maintenance machine instructions is for being executed in conjunction with memory deallocation code, and for updating to said unallocated state said status information for memory deallocated within said memory region by said memory deallocation code;
providing, in a computer storage medium, memory access checking machine instructions for being executed in conjunction with a memory access instruction, for checking said status information for memory within said i 5g memory region accessed by said memory access instructions and for reporting an error if said status information for said accessed memory indicates said unallocated state;
and modifying said set of preexisting machine instructions to produce in a computer storage medium said modified set of machine instructions including said status information maintenance machine instructions, said memory access checking machine instructions, and instructions corresponding to at least a subset of said set of preexisting machine instructions.
The step of providing status information maintenance machine instructions comprises providing status information maintenance machine instructions for storing any of a first predetermined set of bit patterns in memory allocated by said memory allocation code, and for storing any of a second predetermined set of bit patterns in memory deallocated by said memory deallocation code.
The present invention further provides a method for modifying a computer program to have the ability to monitor most of its own memory accesses, wherein memory access types include read and write, said method comprising the steps of:
performing the following steps for substantially all relocatable object files for the program, said relocatable object files containing instruction items of preexisting object code, said instruction items having locations within the preexisting object code:
a) providing a new object code table for storing items in;
i i 5h b) storing, for each instruction item in the preexisting object code, a new code block into the new object code table, said new code block comprising the item and i) memory read monitoring code for items the performance of which involves a memory access of a read type; and ii) memory write monitoring code for items the performance of which involves a memory access of a write type;
c) updating offsets in the new object code table;
c) creating a new relocatable object file comprising the code items from the new object code file.
The present invention also provides a computer implemented method for producing a set of modified machine instructions, said set of modified machine instructions having the ability to maintain memory status information for a region of memory and having the ability to check memory accesses to said region of memory, said set of preexisting memory access instructions corresponding to a set of preexisting memory accesses, said set of preexisting memory access instructions comprising a first group of at least some memory write instructions, for which performance would involve a write access to memory, said set of preexisting memory access instructions further comprising a second group of at least some memory read instructions, for which performance would involve a read access to memory, said memory status information indicating,at least two memory states, said at least two states including an i i 5i initialized state and an uninitialized state, said initialized state corresponding to a memory location initialized by having data for a computer program written thereto, said uninitialized state corresponding to a memory location not having data for said computer program written thereto, said method comprising the steps of:
providing, in a computer storage medium, memory write monitoring machine instructions for updating said status information, for memory in said memory region and accessed by a memory write instruction, from said uninitialized state to said initialized state;
providing, in a computer storage medium, memory read checking machine instructions for signalling an error when memory, in said memory region and accessed by a memory read instruction, is not in said initialized state;
modifying said set of preexisting machine instructions to produce in a computer storage medium said modified set of machine instructions, by for each said memory write instruction, corresponding to a memory write access, modifying said set of preexisting machine instructions to execute said memory write monitoring machine instructions when said memory write access is performed, and for each said memory read instruction, corresponding to a memory read access, modifying said set or preexisting machine instructions to execute said memory read checking machine instructions when said memory read access is performed.
i 5j A further understanding of the nature and advantages of the invention may be realized by reference to the remaining portions of the specification and the drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
Fig . 1 is a block diagram a relocatable obj ect file being expanded by an embodiment of the invention into a new relocatable object file;
Fig. 2 is a block diagram showing the relationship between a relocatable object file and an old object code table' Fig. 3 illustrates the general data/instruction insertion method;
Fig. 4 is a flowchart of the general data/instruction insertion method;
Fig. 5 illustrates the general procedure for implementing a monitoring scheme by modifying the object files for an executable program;
Fig. 6 illustrates the different memory access states used in a particular embodiment of the invention directed to tracking memory access of a program;
Fig. 7 is a virtual memory map showing the portions of virtual memory available to a program;
Fig. 8 illustrates how calls to operating system routines are handled under an embodiment of the invention directed to memory access monitoring;
W093/00633 ;:~ -. f; ; vs '' PCT/US92/04672 Fig. 9 illustrates how the object files for an executable program are processed by an embodiment of the invention directed to memory access monitoring; and Fig. 10 illustrates the formation of new code blocks to implement the memory access monitoring of the preferred embodiment.
DESCRIPTION OF THE PREFERRED EMBODIMENT
.Arbitrary ~,nstruction Insertion ' One aspect of the present invention is a method for expanding a relocatable object file, typically by inserting new instructions and data between preexisting instructions and data of the file, without recompilation being necessary. Fig. 1 illustrates a preexisting object code file 1 ("oldfile.o") being augmented by expansion means 5 to form a new object code file 1' ("newfile.o"). In the preferred embodiment-, expansion means 5 is a general purpose computer having a memory and operating under the control of a computer program. Since expansion means 5 takes object files as input, monitoring schemes can be comprehensive= the method can be applied to all node that goes into the final executable product, not just those portions for which source code is available.
The particular embodiment of expansion means 5 described herebelow is designed for a Sun3/60 running Sun OS 4.1.1, using the v/C++ compilers available from Sun Miarosystams,:~nc., of Mountain View, California, so the description is particular in some respects to that system. In that system, a standard format for relocatable object file 1 (.Q file) has 7 parts, as shown in Fig. 2:
~ A 32 byte header ii, which describes the lengths of the other parts.
~ Hinary machine instructions 12a.
~ Binary data 12b. ' ~ Symbols 13, which have a name (an index into the - string section), a type, a value, and other minor fields .
WO 93/00633 21119 5 8~ ' ', - P~/~592/04672 ~ Instruction relocation data structures 14, which specify which bytes in the instruction section are unresolved references to other data or functions.
~ Data relocation data structures 15, which specify which bytes in the data section are unresolved references to other data or functions.
~ Strings 16, the names of the symbols.
The pre-existing instructions will generally contain many references to other instructions in terms of offsets; that is, in terms of the number of bytes separating the instructions in the object code file, when new instructions are inserted into the code, these offsets are corrected by expansion means 5.
Simply modifying instructions, as opposed to adding new ones, 'may lengthen or. shorten the instruction and also require.
offsets to be corrected. Furthermore, the instructions, symbols, and relocation structures also contain references to data and instructions, and these references will often be in the form of an offset from the beginning of the object file section which contains the data and instructions. Theseware updated in a similar manner.
The value field of certain symbols is an offset into the preexisting instructions and data, and thus must be .
replaced with the~offset of the location to which the preexisting item has been forwarded, The symbols that need updating are'those l~hose type field is one of: N TEXT, N BSS, N DATA, N STSSYM, N LCSYM, N S0, N SOL, N ENTRY, N LBRAC, N_RBRAC AND N_~COI~QrI. Thane symbol types are defined in the - Sun-supplied include file /usr/includa/etab.h (in which "text"
genarally.rafers to instructions). Relocation structures have a field nau~ad :"r_address" which (like the value field of symbols) is an offset into the preexisting instruotiona and data and must be updated with the new location to where the bytes originally pointed to have been moved. In addition, for local relocations, the bytes pointed to by the "r address"
field are themselves an offset that must be updated. ~
The extra instructions inserted are often associated with particular pre-existing instructions and must be executed every time that pre-existing instruction is executed, in some W093100633 ~ 1119 5 8 PCT/US92/04672~
cases just before that pre-existing instruction is executed. , Some of the references to instructions in preexisting object code file 1 will be offsets used to transfer program control to those points during execution. In this case the instruction offsets are adjusted to point to the beginning of the extra code associated with that pre-existing instruction. In other cases, such when a references points to data, even if extra data is inserted around a particular datum, the reference may still need to point directly to that datum. The data and instructions are generally treated as one section. References to both data and instructions are indexed from the beginning of the section containing the instructions and data. Oata may be intermingled with instructions, as well. Expansion means 5 determines whether a particular value in the object file is a datum or an instruction, and also determines the purpose of each reference offset. Furthermore, compilers often put unnamed data, such as constants referred to in the source code, into the instruction section, but not inside a function. To differentiate this data from actual instructions a simplified dead-code analysis is used, starting from the named entry points specified by the symbols of type N TEXT and the entry points derived from the instruction relocation structures. Any instructions that cannot be reached are considered to be data.
bne exception is that some object code libraries of at least one earlier Sun OS,, 4.03, have several named entry points of type N_TEXT that are data, not entry points, and are therefore ignored for these purposes. The names of these data are ~_HYADDR", " NETGROZJP", "_ypsleaptime", and .,~:_ypserv_timaout". AnothAr exception is that at least one compiler, gcc (from the Free Software Foundation), puts named constant data. into the instruction section. ~f the object tile was compiled by gcc, the first word of each named entry point is checked. If it is a link instruction, the entry point is considered a function; otherwise, data, The instruction insertion process of expansion means 5 will now be described in detail with reference to Figs. 2 - 4. Fig. 2 shows a layout in storage media of a relocatable object file 1 containing a section 12 of WO 93/00633 21119 5 8 P~/uS92/04672 instructions 12a and data 12b. Section 12 is copied into a block of memory allocated for the old object code table 2Q (see FILES. C, "Initialize"). F~~ch item in table 20 is indicated generally by a horizontal line, and the byte location for each item is shown to the left side (note: byte locations are_shown in decimal); different items may have different lengths.
Expansion means 5 allocates memory for other tables, shown in Fig. 3: a new object code table 30, a forward index table 40, a forward control index table 50, and an inter-item offset table 60, described below. Then, starting at the beginning of the old object code table 20, each entry in table 20 is processed.
Fig. 4 shows a general flowchart for the method performed by expansion means 5. Block 100 indicates the preparation of tables 20, 30, 40, 50 and 60, described above, and block 110 indicates the step of identifying entry points to functions (see INSERT. C, "FindFunctions"). Block 115 indicates the expansion of~all functions; the details of the expansion process performed on aarh function are shown in the loop composed of blocks 120-190 (see INSERT.C, "DoOneP'unction").
In step 120 of Fig. 4, the first item in the old object coda tabie is ealact~d. Fig. 3 shows parts of memory affected during steps 130 to 200 of the expansion process.
Locations (bytes) 1 to 125 of table 20 have already been processed, and occupy locations 1 to 181 of new object code table 30. The next entry (an object code instruction within a 'function, indicated by its mnemonic "8EQ +6") at location 126 in old object code table 20 is then processed at step 130;
This is a four byte instruction; it begins at location 126, and 3o the next inetructfon,begins at location 126 + 4 ~ 130 (decimal). Two opaode bytes are shown simply as BEQ, and the "6" is a two byte offset pointing to the "RTS" instruction beginning at location 132. Expansion means 5 forms a new code block 33 (see iNSERT.C, "DoOneInstruction"), containing just the 8EQ statement because no additional instructions or data are inserted. The offset is indicated by a question mark in table 30, because its new value is not yet known. Expansion means 5 allocates the maximum of four bytes for the offset, WO 93/00633 ' ~ i- . PCT/US92/04672 21119 5 8 1~
even though the original offset was only two bytes (and the 8EQ
opcode is slightly modified to correspond to a four byte offset). This is done because after expansion, the new offset might be too large for the-number of bytes of the previous offset. . _ Referring to Figs. 3 and 4 together, in step 140 the location of the BEQ instruvtion within new object code table 30 (location = 182) is stored into location 126 of a forward index table 40. In general, the new location of each byte of an instruction is stored in table 40, but in this case, the only entries that are significant are at location 126 of table 40, which indicates that the HEQ statement now begins at location 182 of table 30, and location 128 of table 40, which indicates that the~offset of the BEQ statement now begins at location 184 of table 30. The ellipses ("...") indicate that one or more values are present but have no significance. For example, location 129 of table 40 would correspond to the second byte of the BEQ offset, at location 129 to table 20; however, the .
offset gets expanded from two bytes to four, so the individual bytes of the offset cannot be indexed separately.
Next, in step 150, the location of new code block 33 (location = 182) is stored in forward index control table 50.
Even though there is space for the new locations for each byte of the HEQ 6 statement, only the location of the beginning of the statement is significant. Note that in some expansion schwas, tha~preaxisting instruction might always be located at the beginning of the new code block, in which case the same inforaation would be recorded in both forward index table 40 ~and.in forward control index table 50; dual recordation of this information would, however, be a waste of spaoe. The best approach; therefore, envisions a forward table which, as explaia~d-above, may or may not n~~d to include the two separate sub-tables, forward index table 40 and forward control index table 50.
Next, in step 160, expansion means 5 determines that this instruction contains an inter-item offset (an inter-item offset is a reference to an instruction or datum expressed in terms of its distance in bytes from a second instruction or WO 93/00633 '~ 1 ~ ~ ~ ~ ~ PCT/US92/04672 datum). This determination is made by examining the opcode of the instruction (see iNSERT.C, "RecordPcRelInstr"). &ince this instruction contains an inter-item offset, step 1'70 is performed, whereby the old location of the offset (128 in table 20), _the old location of the base from which the offset_was measured (126 in table 20), and the old size of the offset (2 bytes) are all stored in inter-item offset table 60. For any instruction which denotes the beginning of a switch table of inter-item offsets, each offset is stored in table 6o as above, with the beginning of the switch table entered as the base (see INSERT.C, "DoSwitchTable"). In step 180 the loop is~repeated if any unprocessed items remain. Since there are still more unprocessed items in table 20, step 190 selects the next item, "Add~l,(AO)", and the loop is begun again at step i30.
Repeating steps 130-180, expansion means 5 forms a new code block 35 from the add instruction and new instructions a, 8, and fir, which in this particular case precede the add instruction. This new code block is stored at location 188 of new object code table 30, with the add instruction located at location 194. The location of the add instruction within new object code table 30 (location = 194) is stored into location 130 of a forward index table 40. This indicates that the item which was in location 130 of old object code table 20 is now in location 194 of new object code table 30. The location of new code block 35 within new object code table 30 (location = 188) is~stored in lxation 1:~0 of forward control index table 50.
This indicates that the new coda block formed from the item located at entry 130 of old object code table 20 is located at entry i88 of new object code table 30. The add instruction 3o does not contain an inter-item offset, so nothing is entered into table 60.
Now this oyole is'repeated for the next item in old object code table 20, "RTS" (return from subroutine) at location 132. A new coda block 37 is formed, but it is determined that there ale no new instructions to be inserted with the return instruction, so new code block 37 consists only of the return instruction. New code block 37 is stored at the next available location within new object code table 30, WO 93/00633 ~ . ~ ' -: ~ t : ; PCT/US92104672 f'~ ~ . ; .
211I95g location 198. The location of the return instruction within new object code table 30 is stored into location 132 of forward index table 40; the location of new code block 37 within new object code table 30 is stored in location 132 of forward control index table 50. Since the return instruction and new code block 37 are the same, the number 198 gets stored into location 132 of both index tables. In this example, the return instruction does not contain an inter-item offset, so nothing is stored in inter-item offset table 60. Unnamed constant data is sometimes stored in between functions, after the last instruction of a function and before the next entry point; it ,may be processed as desired or simply copied directly into the new object code table.
After steps 120-X90 have been done for all items in all functions, step 195 repeats the expansion process of blocks 120-190 for all named data. The expansion process is somewhat simpler for data becaLSe it does not contain any offsets such as handled by blocks 160-170. Next, in step 200, expansion means 5 corrects the.int9r-item offsets (see PATCH. C, "PatchPcRal"). The inter-item offset table is examined, and for each set of offsat/base locations in that table, the inter-itam o!loat is patched by: first, adding the indicated offset to its basa.to determine which item in old object code table 20 was targeted by the offset; next, looking up the new location of the targeted item, using forward control index table 50 if the olfsat is uaed,for program control transfer (such as a jump or call), and using forward index table 40 otherwise; also, lookingvup:the new locations of the offset and base, using forward index table 40; and, finally, patching the offset in new object coda table 30 with the diflaranca between the new location of the targeted item and the new location of the base.
_In.this particular example, step a00 involves the offsat/base pair of 128/126. The olfsat is looked up at location 128 in table 20, where the value 6 is found. This is added to the base of 126 to yield a target location of 132.
Because this offset is used in a program control transfer statement (branch), the new target location is looked up in table 50, which provides a new target location of 198. The new WO 93/00633 21119 5 ~ P~T/US92/04672 offset and base locations are looked up in table 40, providing a new base location of 182 and a new offset location of 184.
The difference of i98 minus 182, 16, is then stored at the new offset location, 184. This~process is repeated for all entries in table 60. , --Next, if the obj~ct file contains any symbol tables or relocation tables which are to be corrected, these are analyzed item by item in step 210, and corrected by replacing old item locations with new item locations, as explained above (see also PATCH.C, "PatchTextReloc" and "PatchdataReloc"). The new item locations are looked up in forward index table 40 (except for debugging symbols, the new locations for which are looked up in forward control index table 50). A new object code'file 1' is.now written, using the new object code table as the data/instruct~on section, using the new symbol and relocation tables if corrected, and using the remaining information from the old c~hject file 1.
Memory Access Monitorincr This aspect of the invention is directed to a process of tracking reads and writes of memory by an application program.
in the preferred embodiment, all object files of the applioation program are processed by a memory monitor equipping program that uses the above described expansion means and data/instruction insertion process to insert a function call before ev~ry instruction that includes a memory access, and before some instructions that change the stack pointer. All or ~vsubstantially all of the memory accesses of a given program (not including the memory accesses for instruction fetch) are thereby monitored, for the purposes of performing error checking. All of the object code files for an executable program are processed (except for a library of routines to be added by the memory monitor equipping program , and instructions are added to implement the monitoring schema aescribea below.
The general procedure of implementing a monitoring scheme to discover errors in an executable program, by modifying all of the object code files for the executable 2111958 ~~~ 14 program, linking the modified program and then running it, is illustrated in Fig. 5. A first object file or library for the executable program is selected in block 300. Tf the file is determined to be a simple object file rather than a library, in block 310, then the object file is processed in block 320 to implement a monitoring sct~~me, by the expansion process described above; also, runctions.within the object file may be renamed, as described below. If the file is determined to be a library in block 310, then each object file that contributes to the library is processed in block 330, in the same manner that a simple object file is processed by block 320. Then, in block 340, the library is rebuilt from the modified object files.
After the object file or library has been processed, block 350 determines if any unprocessed files remain for the executable file. If so, block 360 selects an unprocessed file and then the steps of blocks~310-350 are repeated. Once it is determined in block 350 that all files for the original executable program have been processed, all necessary linkage is performed in block 370, which may include linkage with an 2o extra library file including functions specially designed for the monitoring soheme. Thd program is then executed in block 380; during this execution, the monitoring added by the expansion process is performed.
'. In the memory access monitoring method of the preferred embodiment, the expanded code establishes a memory status array with an entry for most memory locations validly accessible by the program, in which two-bit array entries are allocated for each such memory location. Each entry indicates the state of the corresponding memory location, and the state can be one of the following three: (1) unallooat~d and uninitiali$ad (status bits ~ 11); (2) allooated and uininitialiied (status bits ~ 01); and (3) allooated and initialised (status bits ~ 00), eetore each preaxieting instruction that accesses memory or that can change memory status, extra instructions are added to maintain the memory status array, and to use the memory status array to check for the errors of writing to unallocated memory and reading from uninitialized or unallocated memory. A state transition WO 93/00633 ~ PCT/US92/04672 ~11~9~8 diagram is shown in Fig. 6, which illustrates the three states a memory location can have, and how states are changed.
State (1) is indicated by reference numeral 101; state (2), 102; and state (3), 103. The first bit of a status code indicates whether the memory location is unallocated; the second bit indicates whether the memory location is uninitialized. Memory locations in state 1 are unwriteable and unreadable; those in state 2 are writable but unreadable; and those in state 3 are writable and readable.
The status codes generally begin as 11 (state 1, unallocated), and during execution of the modified application program, change as follows: on a successful call to "malloc" (a c memory allocation routin~), the status bits for each byte are set to 01; on a successful call to "free", the status bits for each byte are set to 11; on a successful call to "realloc", the status bits for the old memory are set to 11, and for the new, to 01 (the bits for that part of the new memory that is initialized from the old memory is set to 00). When the stack pointer is decremented, the status bits for the bytes on the stack now allocated are set to 01. When a byte is about to be written, the first bit of its status bits is checked-- if the bit is set, an error is signalled, else the readable bit is cleared (since the byte will now be initialized). Similarly, when a byte is about to k~e read, the second bit of its status bits is checked-- if the bit is set, an error is signalled.
As a special case, when a byte is about to be copied from one vmemory location to another,.the read of uninitialized memory is allowed, but the destination is marked as uninitialized, so that a copy operation on a structure with uninitialized bytes such as those from compiler padding will not cause an error to be signalled. in the preferred embodiment, status checking and changing is handlaa by a group of specialized runtime functions which are oalled at the appropriate points.
Fig. 7 represents the entire 32-bit virtual address space and is not to scale. The memory region 300 at the bottom of the address space, which corresponds to the static information in the program, begins and remains in State 3.
WO 93/00633 ' r . ''. PGT/US92/04672 Memory region 300 contains the instruction codes 301, the data 302, and the BSS data 303 (data loader-initialized to zero).
The bytes in heap 400, which are manipulated via the malloc, realloc, and free functions, change state frequently. This memory is in State 1 to start, then goes to State 2 when it is malloc'd, and to State 3 once it has been written; it goes back to State 1 when it has been freed. Memory region 500 is available to the stack. Memory 500 is in State 1 if it is below the stack pointer. As the stack pointer moves down, parts of this memory become "allocated", and are in State 2.
Once the stack is written to the status goes to State 3. As the stack pointer moves up, it goes back to State 1. It is possible to treat every movement of the stack pointer as an allocation or deallocat9.on, and to call the same routines as are called for malloc and free. This causes signif scant performance degradation, however, because the stack pointer changes frequently. A simplified way to track the status of memory in this region with less status bit maintenance is to compare the location of the referenced memory to the stack pointer. Memory in this region and above the stack pointer is . looked up in the status bit table; memory in this region and below the stack pointer is considered to be in state 1. The method of stack pointer handling by the preferred embodiment is: (a) On entry to a function, where a link instruction allocates stack space for the function's local variables, a call is inserted to mark this affected memory as state 2.
(b) When an argument is pushed onto the stack, a call is inserted to mark the alfactad memory as state 3. (c) When the stack pointer is incremented (reclaiming stack space) nothing is done. This is tied to the method for looking up the status bits for a given byte, which employs the rule, "if the byte is on the stack, but Mlow the stack pointer, then ignoro the bit table, and use the state s (unallocated) bits." (d) Calls to "alloca" are handled specially, and the affected memory is set to status 2.
There is an additional complication for stack variables. Optimizing compilers rearrange code to increase performance; one of the optimizations that they make is to move WO 93/00633 211 i 9 ~ S P~/US92/04672 simple assignments out of loops. Sometimes this can result in an uninitialized stack var'able being accessed, but, the result is not used. Unfortunately, a monitored program would not determine that the result is not used, and would signal an error. Such unnecessary signalling of errors is avoided by inhibiting uninitialized stack variable checks in optimized code by marking local variables in the optimized stack-frame as initialized (i.e., in state 3).
The status bits for the memory from 0 to the top of heap 400 are kept in a first bit-array; the status bits for stack memory 500 are kept in a second bit-array. Virtual memory outside of memory regions 300, 400, and 500 is obtained for storing these bit arrays using the "mmap" system call. To locate the status bits for an arbitrary byte at an address, the method is: if the address is below the top of heap 400, then the bit index is 2 times the address; if the address is in stack memory region 500, tlren the bit index is the address minus address of the bottom of stack region 500, then times 2;
otherwise, the address must be a special address, such as shared memory, and is ignored.
. The current state of a memory location could be indicated without the use of status arrays. The value stored at a memory location would indicate the status of that location. One particular value would represent the unallocated state (state 1), another particular value would represent the allocated and uninitialized state (state 2), and.all othex values would represent user data in state 3. Obviously, however, single-byte values to not have a significant range, so the values representing states 1 and 2 would often occur in valid user data, causing errors to be incorrectly signalled.
This problem could be minimized by using two or four byte sequences to indioata memory statue, reducing the odds of random ocourr~noa, but than single-byte access checking would not be easily supported. For this reason, the use of one or more separate status arrays is believed to be preferable.
The code for operating system routines does not get linked into the user's program. This code is thus not WO 93/00633 '~ r ~~ ~ ~ ~ . ~ FCT/US92/04672 available to be processed according to the invention, and the memory status monitoring code cannot. be inserted. Fox this reason the monitor process must take special measures to track system calls in which the operating system accesses the program's memory directly. The same special measures are also taken to track the heap management functions "malloc", "free", and "realloc".
These special measures are shown in Fig. 8, which shows a process for intercdpting all of the calls to a given set of functions, by modifying the name of every definition (usually there is only one) of these functions, and replacing their old names with new names. Interceptor functions are then provided under the old names; these interceptor functions typically call the intercepted functions as well as having other code. Given a function name, f, and its desired replacement, F, which must not have a longer string length than f, each object file is scanned for external symbols (types N_TEXT and N EXT~ named f. 'For any such instances, the name F
is written over the name f. When the linker runs, the only definition of f will be tl~A interceptor function, and when the program runs the interceptor function f will be called in place of the original f, which has been renamed F. To support the name of F being longer than f, the string table may copied and extended, and then all of the old references, which are in the symbol section, are patched into the new string table.
In the preferred embodiment the data sections of the object code fil~s are expanded with extra dummy entries between each datum or array of data. These extra entries are assigned the status of unallocated and uninitialized, and aid in the detection of array bounds violations and similar data errors.
The praf~rrad embodiment also establishes a list of memory or datum locations which are to be watohpoints with which mor~
comprehensive monitoring is to be performed. Those additional aspects of the preferred r~ubodiment are described in more detail below.
In order to detect many array bounds violations, 8 bytes of memory are allocated before and after each array in - wu 93J00633 PCT/L~S92/04612 the heap, data and bss segments. These 8 bytes are marked as State 1 (unallocated) so that if the program accesses off the end of an array, it will access State 1 memory, and trigger the signalling of an error. For heap arrays, the status bits are set when the array is allocated. For statically allocated arrays, a special 8 byte value (unlikely to be encountered randomly) is inserted between each statically allocated datum.
When the monitored program starts execution, the statically allocated memory is searched for occurrences of the 8 byte value. The status bits for each such occurrence are set to state 1. The error signalling routine looks for the special 8 byte values to print more informative messages ("Array bound violation", in place of "memory access violation"). Stack arrays are not currently delimited with the 8 byte markers, although they could be if so desired.
There are some further complications with this method of tracking arrays, however. Occasionally, either the compiler or the programmer computes the address of the end of an array and uses it as an upper-limit pointer. If the array is defined and the same file upper-limit pointer is used, then the relocation information provided by the compiler is identical to that provided for a reference to the beginning of the next array.. In general, any link-time reference to an address between two data could he intended as either to the end of the first datum or to the beginning of the second. When the data are separated, as described in the preceding paragraph, those two points will no longer be identical. Almost always, the reference is to the beginning of the second, and that assumption can be made. It is possible to implement a check to determine if the reference is used solely as an upper-limit pointer or not, and have the reference patched. accordingly.
Another alternative is to allow the programmer to suppress the insertion of the 8 byte data separator in files that use an upper-limit pointer for locally defined arrays.
Watchpoints are implemented by setting the read and write status bits of the bytes to be watched to 11 (binary) and by adding the location of the watchpoint to a watchpoint list.
When the error signallinc routine is called, the address being 2~119~g checked is compared against the list of current watchpoints.
If there is not a match, the error signalling routine continues normally. Tf there is a match, then the status bits to be manipulated are in a watchpoint-specific data structure, and the error routine calls the watchpoint routine, which typically prints a message, and returns without signalling an error.
The above described memory access monitoring of the preferred embodiment is implemented by the methods illustrated in Figs. 4 and 5, wherein the formation of new code blocks, step 130 of Fig. 4, is performed according to the method described hereinbelow witt: reference to Fig. 10, and wherein function definitions of operating system routines that access memory are intercepted as described above. Also, the original initial entry point to the.program is redefined to point to monitoring setup code, which when finished, transfers to the original initial entry point. The monitoring setup code is thus the first code executed in the modified executable program, and establishes the memory status arrays.
~ Referring to Fig. 10, for this formation of new code blocks, block 130.1 determines the processing of the item according to whether it is an instruction (part of a function) or a datum. If it is a datum, blocks 130.2 to 130.4 copy the 'datum into the new code block with a dummy entry before and after, to enable the array bounds checking described above.
For instructions, it is determined in block 130.5 if they . access memory. If so, block 130.6 adds an instruction to push onto the stack the memory address(es) to be accessed, and block 130.7 adds a call to the appropriate special runtime function that will check and set the appropriate status bits as well as signal errors and handle watchpoints. Finally, in block 130.8, the item itself (the preexisting original instruction) is copied into the new object node table, and the procedure of new code block formation step 130 is completed. The remainder of the method of modifying the executable program and monitoring its execution is as described above with reference to Figs. 4 and 5.
WO 93/00633 ~ PCT/US92/Od672 2211I~~g Alternative Rmbodiments Rather than being added through object code processing, the instructions used to implement monitoring could be added in a compiler based or precompiler based manner, both of which have some advantages and significant disadvantages, however. A compiler normally generates during compilation all the necessary information to implement this monitoring; what is lacking, basically, is for the compiler to add extra code as illustrated in Fig. 10. The disadvantages of this approach are that recompilation for error checking consumes much more time than the above described object code processing, and that source code access to all involved libraries is necessary to ensure comprehensive and accurate error checking. A
precompiler based approach, which would insert extra source code statements into source code files, would suffer all of the disadvantages of a compiler based approach, although it would have portability advantag3s.
Yet another alternative approach would be for the invention to add the monitoring code directly into a previously linked program. Since an executable program has the same basic format as a relocatable object file, the program could be processed as one large object file. This would entail a more involved dead code analysis to distinguish data from instructions, and there would be both relative and absolute addresses to be updated rather than just relative addresses (offsets) .
It is to be understood that the above description is intended to be illustrative and not restrictive. Many other embodiments will be apparent~to those of skill in the art upon reviewing the above description. For instance, provisions for shared memory oould~be made, ouch ae with yet another bit table, but the bit tables should then also be shay~d, and all programs which access the aharad memory should correctly maintain the status codes, Also, another example of a monitoring scheme especially suitable for implementation through the above object code expansion would be standard profiling. The scope of the invention should, therefore, be i WO 93/00633 ; . .. ..j ~ . PCT/US92/04672:
determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
OBJECT CODE FILES AND MONI'~'QRING PROG$AMS
BACKGROUND OF THE INVENTION
The present invention relates generally to a method and apparatus for modifying relocatable object files. In particular, the present invention relates to a method far inserting additional instructions and data into an existing relocatable object file of a computer program, for any purpose.
Most particularly, this purpose is to monitor memory access by 15y the computer program.
Despite the recent increase in CPU speeds and software complexity, most programmers continue to rely on development tools that were designed over fifteen years ago and that have not changed significantly since then. These development tools have serious inadequacies that exacerbate the difficulties of developing large, complex programs.
Problems with developing applications in C/C++ are often more serious than with other programming languages, but are fairl~r typical. C/C++~s pointer and memory management facilities make it difficult to build large, robust programs.
Prudent C/C++ programmers currently hesitate to use many com~arcial object~code libraries because they are worried they may lose weeks of time later on in tracking down wild-pointer bugs introduced by their particular use of a given library.
..
The difficulty in tracking down these kinds of programming bugs and many others is directly tied to the manner in which exaoutabla'code is created from souroe node and to the inadequaoies of current development tools.
The prooess o! transforming source node into "executable" code is, briefly, as follows. The source code for a typical computer program is divided into many files. Some of these files may contain high-level language code, such as C, C++, Pascal, Fortran, Ada, or PL1, and some may contain assembly language code. Each high-level language file is WO 93/00633 21119 ~ ~ f . , PCT/US92/04672 translated by a language-specific compiler into either a relocatable object file, or into an assembly language file. An assembler translates the assembly language files into relocatable object files. A linker merges all of the relocatable object files into a single executable program.
As programs get larger and more complex, they become more difficult to test and debug. If one wants to monitor or analyze aspects of a program's behavior, the current practice is to have the compiler output the extra instructions required to implement the desired monitoring. One example of this exists in many Pascal compilers; there is typically a way to request the compiler to output the extra instructions required to check array bounds at run time, and to signal an error if there is a violation. Another example exists in many vnix/C
compilers; most compilers will, upon request, output extra instructions to r~cord how many times each function was called.
The approach of having the compiler output the extra instructions required to implement a monitoring or analysis scheme is, however, flawed in at least three significant ways:
First, modifying the compiler to output new sequences is difficult, and in practice, nearly impossible, because most programmers don't have the source code to the compiler.
Second, recompiling all of a program's files just to get the extra instructions inserted can be very time consuming and wasteful. Finally, not all code goes through a compiler;' some is'written in assembly language and does not get the new instructions inserted into it. Thus, any monitoring which requires co~~yte coverage to work correctly cannot be implemented through only the compiler.
Some of the most vicious development problems relate to the diffioulty in finding and eliminating a large class of memory-aooea~ related errors. Among the most important memory-acoess related errors that a programmer needs to detect are array bounds violations, uninitialiaed memory reads, free memory access, and data changing strangely.
Array bounds violations (where an array is any collection of data contiguous in memory) occur on those 3 211 ~ ~ ~ g ~ ' ' ~ . PCT/US92/04672 occasions when a program reads or writes past the end, or before the beginning, of an array and accesses whatever datum happens to be in that memory location.
Uninitialized memory reads happen when a program allocates some memory for data storage, but fails to initialize it completely. Later, an uninitialized portion is read, unintentionally providing a random value, which might sometimes cause to the program to fail, and sometimes not.
Free memory access describes the situation where a program deallocates some memory but incorrectly continues to use it. If the program reallocates that memory for another purpose, then it will be using the same memory for two different purposes, and the program will probably perform incorrectly.
"Data changing strangely" is a bit of a catch-all expression. Often there are many ways to change a datum, especially~a "global" datum. The programmer can have a difficult time discovering which function is changing the datum incorrectly, in a given run of the program. What the programmer needs is to have a monitoring program tell him or her whenever a specified datum changes (this is called a watchpoint):
A comprehensive way to monitor the execution of today's and tomorrow's programs, in particular their memory access, is clearly needed by the program developer.
SUMMARY. OF THE INVENTION
~rccording to one aspect of the invention, an object code file ~is'expanded by inserting additional instructions and/or data between preexisting instructions and data, which may also be modified in some ways. A basically unlimited variety of additional instructions and data can be ins~rted for an equally wide variety of purposes. After the insertion step, the offsets in the file are checked and modified, if necessary, to reflect the new positions of the preexisting instructions and data, so that the expanded code will execute properly. in the preferred embodiment additional offsets in symbol tables, data relocation tables and instruction relocation tables are i n updated in the same general manner as the other of f sets .
The basic method is as follows:
An old object code table is formed in memory space, containing the preexisting instructions and data.
Space is also allocated for other tables: a new object code table, an inter-item offset table. For each item in the old object code table (whether instruction or datum), the following four steps are performed: (1) making a new code block comprising any desired additional instructions and/or data and the item, and storing it into the new object code table; (2) storing the location of the item within the new object code table into the forward index table; (3) storing the location of the new code block within the new object code table into the forward control index table; and (4) for items that contain inter-item offsets, storing the location within the old object code table, of the offset and the base from which it is measured, into the inter-item offset table. Then, for each pair of offset/base locations in the inter-item offset table, the offset stored in the new object code table is updated using the index tables. Finally, the offsets in any symbol tables, instruction relocation structures, or data relocation structures in the old object code file are updated so that the new offset refers to the location in the obj ect code table to where the item referred to was moved.
Accordingly, the present invention provides A method for inserting new instructions into a computer program between preexisting instructions, said method comprising the steps of:
a) providing an old object code table containing the preexisting instructions;
i b) providing a new object code table, an inter-item offset table, a forward index table, and a 5 forward control index table, said tables being for storing items in, said items having locations within said tables;
c) performing the following steps for each preexisting instruction in the old object code table:
i) storing a new code block into the new object code table, said new code block comprising any desired new instructions and the preexisting instruction;
ii) storing the location of the preexisting instruction within the new object code table into the forward index table;
iii) storing the location of the new code block within the new object code table into the forward control index table; and iv) for preexisting instructions which contain an inter-item offset, indicating the offset in the inter-item offset table; and d) for each inter-item offset indicated in the inter-item offset table, updating the inter-item offset, using the forward control index table for inter item offsets which are for program control transfer, and using the forward index table otherwise.
The present invention also provides method for inserting new instructions into a relocatable object file having preexisting instructions, data, and linking and debugging auxiliary structures having at least some offsets associated with the preexisting instructions and data, said method comprising the steps of i 5a a) providing an old object code table, a new object code table, an inter-item offset table, a forward index table, and a forward control index table, said tables being for storing items in, said items having locations within said tables;
b) copying the preexisting instructions and data of the object file into the old object code table;
c) performing the following steps for each item in the old object code table;
i) storing a new code block into the new object code table, said new code block comprising any desired new instructions and the item;
ii) storing the location of the item within the new object code table into the forward index table;
iii) storing the location of the new code block within the new object code table into the forward control index table; and iv) for items which contain an inter-item offset pointing to a target and referenced from a base, indicating in the inter-item offset table the locations of the target and base within the old object code table and of the offset in the new object code table, and modifying the item, if necessary, to be consistent with a maximum-byte offset;
d) for each inter-item offset indicated in the inter-item offset table, determining a forward location for the base using the forward index table, determining a forward location for the target using the forward control index table for targets which are program control transfer destinations and using the forward index table otherwise, and updating the inter-item offset in the new i i 5b object code table using the forward locations of the base and target;
e) updating the offsets in the auxiliary structures; and f) creating a new relocatable object file comprising the new object code table and the updated auxiliary structure.
The present invention also provides a method for inserting new instructions into a relocatable object file having preexisting instructions, data, and auxiliary structure, said auxiliary structures having at least some offsets and comprising text relocation structures, data relocation structures, and symbol structures, said method comprising the steps of:
a) providing an entry point table, a new object code table, an inter-item offset table, a forward index table, and a forward control index table, said tables being for storing items in, said items having locations within said tables;
b) providing an old object code table containing the preexisting instructions and data of the object file;
c) for each symbol structure associated with a function and having a function entry address, storing the function entry address in the entry point table, said entry address indicating in the old object code table a first instruction of the function, the function also having a last instruction, all items between the first instruction and last instruction also being instructions of the function;
d) performing the following steps for each i 5c entry address stored in the entry point table:
i) performing the following steps for each preexisting instruction of the function indicated by the entry address:
1) storing a new code block into the new object code table, said new code block comprising any desired new instructions and the preexisting instruction;
2) storing the location of the preexisting instruction within the new object code table into the forward index table;
3) storing the location of the new code block within the new object code table into the forward control index table; and 4) for preexisting instructions that contain an inter-item offset pointing to a target and referenced from a base, indicating in the inter-item offset table the locations of the target and base within the old object code table and of the offset in the new object code table, and modifying the preexisting instructions in the new code block, if necessary, to be consistent with a maximum-byte offset; and ii) performing the following steps for each item in the old object code table after the last preexisting instruction of the function indicated by the entry address and before a closest next entry address:
1) copying the item into the new object code table;
2) storing the location of the item within the new object code table into the forward index table;
i .;
5d e) for each inter-item offset indicated in the inter-item offset table, determining a forward location for the base using the forward index table, determining a forward location for the target using the forward control index table for targets which are program control transfer destinations and using the forward index table otherwise, and updating the inter-item offset in the new object code table using the forward locations of the base and target;
f) updating offsets in the auxiliary structures; and g) creating a new relocatable object file comprising the new object code table and the updated auxiliary structures.
According to a second aspect of the invention, all or substantially all the memory accesses of a given program are monitored (not including the memory accesses fox instruction fetch), for the purposes of performing error-checking. In one embodiment, all the object code files for an executable program are processed, and instructions are added to implement the following monitoring scheme. A memory status array is established, with an entry for most memory locations that are validly accessible by the program. Each entry indicates the state of the corresponding memory location, and the state can be one of the following three: unallocated and uninitialized, allocated but uninitialized, and allocated and initialized. Before each preexisting instruction which accesses memory or which can change memory status, extra instructions are added to maintain the memory status array, and to use the memory status array to check i n 5e for the errors of writing to unallocated memory and reading from unallocated or uninitialized memory. In one particular embodiment, the data sections of the object code files are expanded with extra dummy entries between each datum. These extra entries are assigned the status of unallocated and uninitialized, and aid in the detection of array bounds violations and similar data errors. In another particular embodiment, a list is stored of memory or datum locations which are to be watchpoints with which more comprehensive monitoring is to be performed.
Accordingly, the present invention provides a method of modifying a computer program to have the ability to monitor most of its own memory accesses, said computer program having preexisting code items, said method comprising the steps of a) for most preexisting code items the performance of which involves a memory read, adding memory read monitoring code located so that it will be executed each time the memory read preexisting code item is executed; and b) for most preexisting code items the performance of which involves a memory write, adding memory write monitoring code located so that it will be executed each time the memory write preexisting code item is executed.
The present invention also provides a computer implemented method for producing a set of modified machine instrucdtions from a set of preexisting machine instructions, said set of modified machine instructions having the ability to maintain memory status i 5f information for a region of memory and having the ability to check memory accesses to said region of memory, said set of preexisting machine instructions corresponding to a set of preexisting memory accesses to region of memory, said memory status information indicating at least two memory states, said at least two memory states including an allocated state and an unallocated state, said allocated state corresponding to a memory location allocated by a computer program, and said unallocated state corresponding to a memory location not allocated by said computer program, said method comprising the steps of providing in a computer storage medium, status information maintenance machine instructions, wherein at least a first portion of said status information maintenance machine instructions is for being executed in conjunction with memory allocation code, and for updating to said allocation state said status information for memory allocated within said memory region by said memory allocation code, and at least a second portion of said status information maintenance machine instructions is for being executed in conjunction with memory deallocation code, and for updating to said unallocated state said status information for memory deallocated within said memory region by said memory deallocation code;
providing, in a computer storage medium, memory access checking machine instructions for being executed in conjunction with a memory access instruction, for checking said status information for memory within said i 5g memory region accessed by said memory access instructions and for reporting an error if said status information for said accessed memory indicates said unallocated state;
and modifying said set of preexisting machine instructions to produce in a computer storage medium said modified set of machine instructions including said status information maintenance machine instructions, said memory access checking machine instructions, and instructions corresponding to at least a subset of said set of preexisting machine instructions.
The step of providing status information maintenance machine instructions comprises providing status information maintenance machine instructions for storing any of a first predetermined set of bit patterns in memory allocated by said memory allocation code, and for storing any of a second predetermined set of bit patterns in memory deallocated by said memory deallocation code.
The present invention further provides a method for modifying a computer program to have the ability to monitor most of its own memory accesses, wherein memory access types include read and write, said method comprising the steps of:
performing the following steps for substantially all relocatable object files for the program, said relocatable object files containing instruction items of preexisting object code, said instruction items having locations within the preexisting object code:
a) providing a new object code table for storing items in;
i i 5h b) storing, for each instruction item in the preexisting object code, a new code block into the new object code table, said new code block comprising the item and i) memory read monitoring code for items the performance of which involves a memory access of a read type; and ii) memory write monitoring code for items the performance of which involves a memory access of a write type;
c) updating offsets in the new object code table;
c) creating a new relocatable object file comprising the code items from the new object code file.
The present invention also provides a computer implemented method for producing a set of modified machine instructions, said set of modified machine instructions having the ability to maintain memory status information for a region of memory and having the ability to check memory accesses to said region of memory, said set of preexisting memory access instructions corresponding to a set of preexisting memory accesses, said set of preexisting memory access instructions comprising a first group of at least some memory write instructions, for which performance would involve a write access to memory, said set of preexisting memory access instructions further comprising a second group of at least some memory read instructions, for which performance would involve a read access to memory, said memory status information indicating,at least two memory states, said at least two states including an i i 5i initialized state and an uninitialized state, said initialized state corresponding to a memory location initialized by having data for a computer program written thereto, said uninitialized state corresponding to a memory location not having data for said computer program written thereto, said method comprising the steps of:
providing, in a computer storage medium, memory write monitoring machine instructions for updating said status information, for memory in said memory region and accessed by a memory write instruction, from said uninitialized state to said initialized state;
providing, in a computer storage medium, memory read checking machine instructions for signalling an error when memory, in said memory region and accessed by a memory read instruction, is not in said initialized state;
modifying said set of preexisting machine instructions to produce in a computer storage medium said modified set of machine instructions, by for each said memory write instruction, corresponding to a memory write access, modifying said set of preexisting machine instructions to execute said memory write monitoring machine instructions when said memory write access is performed, and for each said memory read instruction, corresponding to a memory read access, modifying said set or preexisting machine instructions to execute said memory read checking machine instructions when said memory read access is performed.
i 5j A further understanding of the nature and advantages of the invention may be realized by reference to the remaining portions of the specification and the drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
Fig . 1 is a block diagram a relocatable obj ect file being expanded by an embodiment of the invention into a new relocatable object file;
Fig. 2 is a block diagram showing the relationship between a relocatable object file and an old object code table' Fig. 3 illustrates the general data/instruction insertion method;
Fig. 4 is a flowchart of the general data/instruction insertion method;
Fig. 5 illustrates the general procedure for implementing a monitoring scheme by modifying the object files for an executable program;
Fig. 6 illustrates the different memory access states used in a particular embodiment of the invention directed to tracking memory access of a program;
Fig. 7 is a virtual memory map showing the portions of virtual memory available to a program;
Fig. 8 illustrates how calls to operating system routines are handled under an embodiment of the invention directed to memory access monitoring;
W093/00633 ;:~ -. f; ; vs '' PCT/US92/04672 Fig. 9 illustrates how the object files for an executable program are processed by an embodiment of the invention directed to memory access monitoring; and Fig. 10 illustrates the formation of new code blocks to implement the memory access monitoring of the preferred embodiment.
DESCRIPTION OF THE PREFERRED EMBODIMENT
.Arbitrary ~,nstruction Insertion ' One aspect of the present invention is a method for expanding a relocatable object file, typically by inserting new instructions and data between preexisting instructions and data of the file, without recompilation being necessary. Fig. 1 illustrates a preexisting object code file 1 ("oldfile.o") being augmented by expansion means 5 to form a new object code file 1' ("newfile.o"). In the preferred embodiment-, expansion means 5 is a general purpose computer having a memory and operating under the control of a computer program. Since expansion means 5 takes object files as input, monitoring schemes can be comprehensive= the method can be applied to all node that goes into the final executable product, not just those portions for which source code is available.
The particular embodiment of expansion means 5 described herebelow is designed for a Sun3/60 running Sun OS 4.1.1, using the v/C++ compilers available from Sun Miarosystams,:~nc., of Mountain View, California, so the description is particular in some respects to that system. In that system, a standard format for relocatable object file 1 (.Q file) has 7 parts, as shown in Fig. 2:
~ A 32 byte header ii, which describes the lengths of the other parts.
~ Hinary machine instructions 12a.
~ Binary data 12b. ' ~ Symbols 13, which have a name (an index into the - string section), a type, a value, and other minor fields .
WO 93/00633 21119 5 8~ ' ', - P~/~592/04672 ~ Instruction relocation data structures 14, which specify which bytes in the instruction section are unresolved references to other data or functions.
~ Data relocation data structures 15, which specify which bytes in the data section are unresolved references to other data or functions.
~ Strings 16, the names of the symbols.
The pre-existing instructions will generally contain many references to other instructions in terms of offsets; that is, in terms of the number of bytes separating the instructions in the object code file, when new instructions are inserted into the code, these offsets are corrected by expansion means 5.
Simply modifying instructions, as opposed to adding new ones, 'may lengthen or. shorten the instruction and also require.
offsets to be corrected. Furthermore, the instructions, symbols, and relocation structures also contain references to data and instructions, and these references will often be in the form of an offset from the beginning of the object file section which contains the data and instructions. Theseware updated in a similar manner.
The value field of certain symbols is an offset into the preexisting instructions and data, and thus must be .
replaced with the~offset of the location to which the preexisting item has been forwarded, The symbols that need updating are'those l~hose type field is one of: N TEXT, N BSS, N DATA, N STSSYM, N LCSYM, N S0, N SOL, N ENTRY, N LBRAC, N_RBRAC AND N_~COI~QrI. Thane symbol types are defined in the - Sun-supplied include file /usr/includa/etab.h (in which "text"
genarally.rafers to instructions). Relocation structures have a field nau~ad :"r_address" which (like the value field of symbols) is an offset into the preexisting instruotiona and data and must be updated with the new location to where the bytes originally pointed to have been moved. In addition, for local relocations, the bytes pointed to by the "r address"
field are themselves an offset that must be updated. ~
The extra instructions inserted are often associated with particular pre-existing instructions and must be executed every time that pre-existing instruction is executed, in some W093100633 ~ 1119 5 8 PCT/US92/04672~
cases just before that pre-existing instruction is executed. , Some of the references to instructions in preexisting object code file 1 will be offsets used to transfer program control to those points during execution. In this case the instruction offsets are adjusted to point to the beginning of the extra code associated with that pre-existing instruction. In other cases, such when a references points to data, even if extra data is inserted around a particular datum, the reference may still need to point directly to that datum. The data and instructions are generally treated as one section. References to both data and instructions are indexed from the beginning of the section containing the instructions and data. Oata may be intermingled with instructions, as well. Expansion means 5 determines whether a particular value in the object file is a datum or an instruction, and also determines the purpose of each reference offset. Furthermore, compilers often put unnamed data, such as constants referred to in the source code, into the instruction section, but not inside a function. To differentiate this data from actual instructions a simplified dead-code analysis is used, starting from the named entry points specified by the symbols of type N TEXT and the entry points derived from the instruction relocation structures. Any instructions that cannot be reached are considered to be data.
bne exception is that some object code libraries of at least one earlier Sun OS,, 4.03, have several named entry points of type N_TEXT that are data, not entry points, and are therefore ignored for these purposes. The names of these data are ~_HYADDR", " NETGROZJP", "_ypsleaptime", and .,~:_ypserv_timaout". AnothAr exception is that at least one compiler, gcc (from the Free Software Foundation), puts named constant data. into the instruction section. ~f the object tile was compiled by gcc, the first word of each named entry point is checked. If it is a link instruction, the entry point is considered a function; otherwise, data, The instruction insertion process of expansion means 5 will now be described in detail with reference to Figs. 2 - 4. Fig. 2 shows a layout in storage media of a relocatable object file 1 containing a section 12 of WO 93/00633 21119 5 8 P~/uS92/04672 instructions 12a and data 12b. Section 12 is copied into a block of memory allocated for the old object code table 2Q (see FILES. C, "Initialize"). F~~ch item in table 20 is indicated generally by a horizontal line, and the byte location for each item is shown to the left side (note: byte locations are_shown in decimal); different items may have different lengths.
Expansion means 5 allocates memory for other tables, shown in Fig. 3: a new object code table 30, a forward index table 40, a forward control index table 50, and an inter-item offset table 60, described below. Then, starting at the beginning of the old object code table 20, each entry in table 20 is processed.
Fig. 4 shows a general flowchart for the method performed by expansion means 5. Block 100 indicates the preparation of tables 20, 30, 40, 50 and 60, described above, and block 110 indicates the step of identifying entry points to functions (see INSERT. C, "FindFunctions"). Block 115 indicates the expansion of~all functions; the details of the expansion process performed on aarh function are shown in the loop composed of blocks 120-190 (see INSERT.C, "DoOneP'unction").
In step 120 of Fig. 4, the first item in the old object coda tabie is ealact~d. Fig. 3 shows parts of memory affected during steps 130 to 200 of the expansion process.
Locations (bytes) 1 to 125 of table 20 have already been processed, and occupy locations 1 to 181 of new object code table 30. The next entry (an object code instruction within a 'function, indicated by its mnemonic "8EQ +6") at location 126 in old object code table 20 is then processed at step 130;
This is a four byte instruction; it begins at location 126, and 3o the next inetructfon,begins at location 126 + 4 ~ 130 (decimal). Two opaode bytes are shown simply as BEQ, and the "6" is a two byte offset pointing to the "RTS" instruction beginning at location 132. Expansion means 5 forms a new code block 33 (see iNSERT.C, "DoOneInstruction"), containing just the 8EQ statement because no additional instructions or data are inserted. The offset is indicated by a question mark in table 30, because its new value is not yet known. Expansion means 5 allocates the maximum of four bytes for the offset, WO 93/00633 ' ~ i- . PCT/US92/04672 21119 5 8 1~
even though the original offset was only two bytes (and the 8EQ
opcode is slightly modified to correspond to a four byte offset). This is done because after expansion, the new offset might be too large for the-number of bytes of the previous offset. . _ Referring to Figs. 3 and 4 together, in step 140 the location of the BEQ instruvtion within new object code table 30 (location = 182) is stored into location 126 of a forward index table 40. In general, the new location of each byte of an instruction is stored in table 40, but in this case, the only entries that are significant are at location 126 of table 40, which indicates that the HEQ statement now begins at location 182 of table 30, and location 128 of table 40, which indicates that the~offset of the BEQ statement now begins at location 184 of table 30. The ellipses ("...") indicate that one or more values are present but have no significance. For example, location 129 of table 40 would correspond to the second byte of the BEQ offset, at location 129 to table 20; however, the .
offset gets expanded from two bytes to four, so the individual bytes of the offset cannot be indexed separately.
Next, in step 150, the location of new code block 33 (location = 182) is stored in forward index control table 50.
Even though there is space for the new locations for each byte of the HEQ 6 statement, only the location of the beginning of the statement is significant. Note that in some expansion schwas, tha~preaxisting instruction might always be located at the beginning of the new code block, in which case the same inforaation would be recorded in both forward index table 40 ~and.in forward control index table 50; dual recordation of this information would, however, be a waste of spaoe. The best approach; therefore, envisions a forward table which, as explaia~d-above, may or may not n~~d to include the two separate sub-tables, forward index table 40 and forward control index table 50.
Next, in step 160, expansion means 5 determines that this instruction contains an inter-item offset (an inter-item offset is a reference to an instruction or datum expressed in terms of its distance in bytes from a second instruction or WO 93/00633 '~ 1 ~ ~ ~ ~ ~ PCT/US92/04672 datum). This determination is made by examining the opcode of the instruction (see iNSERT.C, "RecordPcRelInstr"). &ince this instruction contains an inter-item offset, step 1'70 is performed, whereby the old location of the offset (128 in table 20), _the old location of the base from which the offset_was measured (126 in table 20), and the old size of the offset (2 bytes) are all stored in inter-item offset table 60. For any instruction which denotes the beginning of a switch table of inter-item offsets, each offset is stored in table 6o as above, with the beginning of the switch table entered as the base (see INSERT.C, "DoSwitchTable"). In step 180 the loop is~repeated if any unprocessed items remain. Since there are still more unprocessed items in table 20, step 190 selects the next item, "Add~l,(AO)", and the loop is begun again at step i30.
Repeating steps 130-180, expansion means 5 forms a new code block 35 from the add instruction and new instructions a, 8, and fir, which in this particular case precede the add instruction. This new code block is stored at location 188 of new object code table 30, with the add instruction located at location 194. The location of the add instruction within new object code table 30 (location = 194) is stored into location 130 of a forward index table 40. This indicates that the item which was in location 130 of old object code table 20 is now in location 194 of new object code table 30. The location of new code block 35 within new object code table 30 (location = 188) is~stored in lxation 1:~0 of forward control index table 50.
This indicates that the new coda block formed from the item located at entry 130 of old object code table 20 is located at entry i88 of new object code table 30. The add instruction 3o does not contain an inter-item offset, so nothing is entered into table 60.
Now this oyole is'repeated for the next item in old object code table 20, "RTS" (return from subroutine) at location 132. A new coda block 37 is formed, but it is determined that there ale no new instructions to be inserted with the return instruction, so new code block 37 consists only of the return instruction. New code block 37 is stored at the next available location within new object code table 30, WO 93/00633 ~ . ~ ' -: ~ t : ; PCT/US92104672 f'~ ~ . ; .
211I95g location 198. The location of the return instruction within new object code table 30 is stored into location 132 of forward index table 40; the location of new code block 37 within new object code table 30 is stored in location 132 of forward control index table 50. Since the return instruction and new code block 37 are the same, the number 198 gets stored into location 132 of both index tables. In this example, the return instruction does not contain an inter-item offset, so nothing is stored in inter-item offset table 60. Unnamed constant data is sometimes stored in between functions, after the last instruction of a function and before the next entry point; it ,may be processed as desired or simply copied directly into the new object code table.
After steps 120-X90 have been done for all items in all functions, step 195 repeats the expansion process of blocks 120-190 for all named data. The expansion process is somewhat simpler for data becaLSe it does not contain any offsets such as handled by blocks 160-170. Next, in step 200, expansion means 5 corrects the.int9r-item offsets (see PATCH. C, "PatchPcRal"). The inter-item offset table is examined, and for each set of offsat/base locations in that table, the inter-itam o!loat is patched by: first, adding the indicated offset to its basa.to determine which item in old object code table 20 was targeted by the offset; next, looking up the new location of the targeted item, using forward control index table 50 if the olfsat is uaed,for program control transfer (such as a jump or call), and using forward index table 40 otherwise; also, lookingvup:the new locations of the offset and base, using forward index table 40; and, finally, patching the offset in new object coda table 30 with the diflaranca between the new location of the targeted item and the new location of the base.
_In.this particular example, step a00 involves the offsat/base pair of 128/126. The olfsat is looked up at location 128 in table 20, where the value 6 is found. This is added to the base of 126 to yield a target location of 132.
Because this offset is used in a program control transfer statement (branch), the new target location is looked up in table 50, which provides a new target location of 198. The new WO 93/00633 21119 5 ~ P~T/US92/04672 offset and base locations are looked up in table 40, providing a new base location of 182 and a new offset location of 184.
The difference of i98 minus 182, 16, is then stored at the new offset location, 184. This~process is repeated for all entries in table 60. , --Next, if the obj~ct file contains any symbol tables or relocation tables which are to be corrected, these are analyzed item by item in step 210, and corrected by replacing old item locations with new item locations, as explained above (see also PATCH.C, "PatchTextReloc" and "PatchdataReloc"). The new item locations are looked up in forward index table 40 (except for debugging symbols, the new locations for which are looked up in forward control index table 50). A new object code'file 1' is.now written, using the new object code table as the data/instruct~on section, using the new symbol and relocation tables if corrected, and using the remaining information from the old c~hject file 1.
Memory Access Monitorincr This aspect of the invention is directed to a process of tracking reads and writes of memory by an application program.
in the preferred embodiment, all object files of the applioation program are processed by a memory monitor equipping program that uses the above described expansion means and data/instruction insertion process to insert a function call before ev~ry instruction that includes a memory access, and before some instructions that change the stack pointer. All or ~vsubstantially all of the memory accesses of a given program (not including the memory accesses for instruction fetch) are thereby monitored, for the purposes of performing error checking. All of the object code files for an executable program are processed (except for a library of routines to be added by the memory monitor equipping program , and instructions are added to implement the monitoring schema aescribea below.
The general procedure of implementing a monitoring scheme to discover errors in an executable program, by modifying all of the object code files for the executable 2111958 ~~~ 14 program, linking the modified program and then running it, is illustrated in Fig. 5. A first object file or library for the executable program is selected in block 300. Tf the file is determined to be a simple object file rather than a library, in block 310, then the object file is processed in block 320 to implement a monitoring sct~~me, by the expansion process described above; also, runctions.within the object file may be renamed, as described below. If the file is determined to be a library in block 310, then each object file that contributes to the library is processed in block 330, in the same manner that a simple object file is processed by block 320. Then, in block 340, the library is rebuilt from the modified object files.
After the object file or library has been processed, block 350 determines if any unprocessed files remain for the executable file. If so, block 360 selects an unprocessed file and then the steps of blocks~310-350 are repeated. Once it is determined in block 350 that all files for the original executable program have been processed, all necessary linkage is performed in block 370, which may include linkage with an 2o extra library file including functions specially designed for the monitoring soheme. Thd program is then executed in block 380; during this execution, the monitoring added by the expansion process is performed.
'. In the memory access monitoring method of the preferred embodiment, the expanded code establishes a memory status array with an entry for most memory locations validly accessible by the program, in which two-bit array entries are allocated for each such memory location. Each entry indicates the state of the corresponding memory location, and the state can be one of the following three: (1) unallooat~d and uninitiali$ad (status bits ~ 11); (2) allooated and uininitialiied (status bits ~ 01); and (3) allooated and initialised (status bits ~ 00), eetore each preaxieting instruction that accesses memory or that can change memory status, extra instructions are added to maintain the memory status array, and to use the memory status array to check for the errors of writing to unallocated memory and reading from uninitialized or unallocated memory. A state transition WO 93/00633 ~ PCT/US92/04672 ~11~9~8 diagram is shown in Fig. 6, which illustrates the three states a memory location can have, and how states are changed.
State (1) is indicated by reference numeral 101; state (2), 102; and state (3), 103. The first bit of a status code indicates whether the memory location is unallocated; the second bit indicates whether the memory location is uninitialized. Memory locations in state 1 are unwriteable and unreadable; those in state 2 are writable but unreadable; and those in state 3 are writable and readable.
The status codes generally begin as 11 (state 1, unallocated), and during execution of the modified application program, change as follows: on a successful call to "malloc" (a c memory allocation routin~), the status bits for each byte are set to 01; on a successful call to "free", the status bits for each byte are set to 11; on a successful call to "realloc", the status bits for the old memory are set to 11, and for the new, to 01 (the bits for that part of the new memory that is initialized from the old memory is set to 00). When the stack pointer is decremented, the status bits for the bytes on the stack now allocated are set to 01. When a byte is about to be written, the first bit of its status bits is checked-- if the bit is set, an error is signalled, else the readable bit is cleared (since the byte will now be initialized). Similarly, when a byte is about to k~e read, the second bit of its status bits is checked-- if the bit is set, an error is signalled.
As a special case, when a byte is about to be copied from one vmemory location to another,.the read of uninitialized memory is allowed, but the destination is marked as uninitialized, so that a copy operation on a structure with uninitialized bytes such as those from compiler padding will not cause an error to be signalled. in the preferred embodiment, status checking and changing is handlaa by a group of specialized runtime functions which are oalled at the appropriate points.
Fig. 7 represents the entire 32-bit virtual address space and is not to scale. The memory region 300 at the bottom of the address space, which corresponds to the static information in the program, begins and remains in State 3.
WO 93/00633 ' r . ''. PGT/US92/04672 Memory region 300 contains the instruction codes 301, the data 302, and the BSS data 303 (data loader-initialized to zero).
The bytes in heap 400, which are manipulated via the malloc, realloc, and free functions, change state frequently. This memory is in State 1 to start, then goes to State 2 when it is malloc'd, and to State 3 once it has been written; it goes back to State 1 when it has been freed. Memory region 500 is available to the stack. Memory 500 is in State 1 if it is below the stack pointer. As the stack pointer moves down, parts of this memory become "allocated", and are in State 2.
Once the stack is written to the status goes to State 3. As the stack pointer moves up, it goes back to State 1. It is possible to treat every movement of the stack pointer as an allocation or deallocat9.on, and to call the same routines as are called for malloc and free. This causes signif scant performance degradation, however, because the stack pointer changes frequently. A simplified way to track the status of memory in this region with less status bit maintenance is to compare the location of the referenced memory to the stack pointer. Memory in this region and above the stack pointer is . looked up in the status bit table; memory in this region and below the stack pointer is considered to be in state 1. The method of stack pointer handling by the preferred embodiment is: (a) On entry to a function, where a link instruction allocates stack space for the function's local variables, a call is inserted to mark this affected memory as state 2.
(b) When an argument is pushed onto the stack, a call is inserted to mark the alfactad memory as state 3. (c) When the stack pointer is incremented (reclaiming stack space) nothing is done. This is tied to the method for looking up the status bits for a given byte, which employs the rule, "if the byte is on the stack, but Mlow the stack pointer, then ignoro the bit table, and use the state s (unallocated) bits." (d) Calls to "alloca" are handled specially, and the affected memory is set to status 2.
There is an additional complication for stack variables. Optimizing compilers rearrange code to increase performance; one of the optimizations that they make is to move WO 93/00633 211 i 9 ~ S P~/US92/04672 simple assignments out of loops. Sometimes this can result in an uninitialized stack var'able being accessed, but, the result is not used. Unfortunately, a monitored program would not determine that the result is not used, and would signal an error. Such unnecessary signalling of errors is avoided by inhibiting uninitialized stack variable checks in optimized code by marking local variables in the optimized stack-frame as initialized (i.e., in state 3).
The status bits for the memory from 0 to the top of heap 400 are kept in a first bit-array; the status bits for stack memory 500 are kept in a second bit-array. Virtual memory outside of memory regions 300, 400, and 500 is obtained for storing these bit arrays using the "mmap" system call. To locate the status bits for an arbitrary byte at an address, the method is: if the address is below the top of heap 400, then the bit index is 2 times the address; if the address is in stack memory region 500, tlren the bit index is the address minus address of the bottom of stack region 500, then times 2;
otherwise, the address must be a special address, such as shared memory, and is ignored.
. The current state of a memory location could be indicated without the use of status arrays. The value stored at a memory location would indicate the status of that location. One particular value would represent the unallocated state (state 1), another particular value would represent the allocated and uninitialized state (state 2), and.all othex values would represent user data in state 3. Obviously, however, single-byte values to not have a significant range, so the values representing states 1 and 2 would often occur in valid user data, causing errors to be incorrectly signalled.
This problem could be minimized by using two or four byte sequences to indioata memory statue, reducing the odds of random ocourr~noa, but than single-byte access checking would not be easily supported. For this reason, the use of one or more separate status arrays is believed to be preferable.
The code for operating system routines does not get linked into the user's program. This code is thus not WO 93/00633 '~ r ~~ ~ ~ ~ . ~ FCT/US92/04672 available to be processed according to the invention, and the memory status monitoring code cannot. be inserted. Fox this reason the monitor process must take special measures to track system calls in which the operating system accesses the program's memory directly. The same special measures are also taken to track the heap management functions "malloc", "free", and "realloc".
These special measures are shown in Fig. 8, which shows a process for intercdpting all of the calls to a given set of functions, by modifying the name of every definition (usually there is only one) of these functions, and replacing their old names with new names. Interceptor functions are then provided under the old names; these interceptor functions typically call the intercepted functions as well as having other code. Given a function name, f, and its desired replacement, F, which must not have a longer string length than f, each object file is scanned for external symbols (types N_TEXT and N EXT~ named f. 'For any such instances, the name F
is written over the name f. When the linker runs, the only definition of f will be tl~A interceptor function, and when the program runs the interceptor function f will be called in place of the original f, which has been renamed F. To support the name of F being longer than f, the string table may copied and extended, and then all of the old references, which are in the symbol section, are patched into the new string table.
In the preferred embodiment the data sections of the object code fil~s are expanded with extra dummy entries between each datum or array of data. These extra entries are assigned the status of unallocated and uninitialized, and aid in the detection of array bounds violations and similar data errors.
The praf~rrad embodiment also establishes a list of memory or datum locations which are to be watohpoints with which mor~
comprehensive monitoring is to be performed. Those additional aspects of the preferred r~ubodiment are described in more detail below.
In order to detect many array bounds violations, 8 bytes of memory are allocated before and after each array in - wu 93J00633 PCT/L~S92/04612 the heap, data and bss segments. These 8 bytes are marked as State 1 (unallocated) so that if the program accesses off the end of an array, it will access State 1 memory, and trigger the signalling of an error. For heap arrays, the status bits are set when the array is allocated. For statically allocated arrays, a special 8 byte value (unlikely to be encountered randomly) is inserted between each statically allocated datum.
When the monitored program starts execution, the statically allocated memory is searched for occurrences of the 8 byte value. The status bits for each such occurrence are set to state 1. The error signalling routine looks for the special 8 byte values to print more informative messages ("Array bound violation", in place of "memory access violation"). Stack arrays are not currently delimited with the 8 byte markers, although they could be if so desired.
There are some further complications with this method of tracking arrays, however. Occasionally, either the compiler or the programmer computes the address of the end of an array and uses it as an upper-limit pointer. If the array is defined and the same file upper-limit pointer is used, then the relocation information provided by the compiler is identical to that provided for a reference to the beginning of the next array.. In general, any link-time reference to an address between two data could he intended as either to the end of the first datum or to the beginning of the second. When the data are separated, as described in the preceding paragraph, those two points will no longer be identical. Almost always, the reference is to the beginning of the second, and that assumption can be made. It is possible to implement a check to determine if the reference is used solely as an upper-limit pointer or not, and have the reference patched. accordingly.
Another alternative is to allow the programmer to suppress the insertion of the 8 byte data separator in files that use an upper-limit pointer for locally defined arrays.
Watchpoints are implemented by setting the read and write status bits of the bytes to be watched to 11 (binary) and by adding the location of the watchpoint to a watchpoint list.
When the error signallinc routine is called, the address being 2~119~g checked is compared against the list of current watchpoints.
If there is not a match, the error signalling routine continues normally. Tf there is a match, then the status bits to be manipulated are in a watchpoint-specific data structure, and the error routine calls the watchpoint routine, which typically prints a message, and returns without signalling an error.
The above described memory access monitoring of the preferred embodiment is implemented by the methods illustrated in Figs. 4 and 5, wherein the formation of new code blocks, step 130 of Fig. 4, is performed according to the method described hereinbelow witt: reference to Fig. 10, and wherein function definitions of operating system routines that access memory are intercepted as described above. Also, the original initial entry point to the.program is redefined to point to monitoring setup code, which when finished, transfers to the original initial entry point. The monitoring setup code is thus the first code executed in the modified executable program, and establishes the memory status arrays.
~ Referring to Fig. 10, for this formation of new code blocks, block 130.1 determines the processing of the item according to whether it is an instruction (part of a function) or a datum. If it is a datum, blocks 130.2 to 130.4 copy the 'datum into the new code block with a dummy entry before and after, to enable the array bounds checking described above.
For instructions, it is determined in block 130.5 if they . access memory. If so, block 130.6 adds an instruction to push onto the stack the memory address(es) to be accessed, and block 130.7 adds a call to the appropriate special runtime function that will check and set the appropriate status bits as well as signal errors and handle watchpoints. Finally, in block 130.8, the item itself (the preexisting original instruction) is copied into the new object node table, and the procedure of new code block formation step 130 is completed. The remainder of the method of modifying the executable program and monitoring its execution is as described above with reference to Figs. 4 and 5.
WO 93/00633 ~ PCT/US92/Od672 2211I~~g Alternative Rmbodiments Rather than being added through object code processing, the instructions used to implement monitoring could be added in a compiler based or precompiler based manner, both of which have some advantages and significant disadvantages, however. A compiler normally generates during compilation all the necessary information to implement this monitoring; what is lacking, basically, is for the compiler to add extra code as illustrated in Fig. 10. The disadvantages of this approach are that recompilation for error checking consumes much more time than the above described object code processing, and that source code access to all involved libraries is necessary to ensure comprehensive and accurate error checking. A
precompiler based approach, which would insert extra source code statements into source code files, would suffer all of the disadvantages of a compiler based approach, although it would have portability advantag3s.
Yet another alternative approach would be for the invention to add the monitoring code directly into a previously linked program. Since an executable program has the same basic format as a relocatable object file, the program could be processed as one large object file. This would entail a more involved dead code analysis to distinguish data from instructions, and there would be both relative and absolute addresses to be updated rather than just relative addresses (offsets) .
It is to be understood that the above description is intended to be illustrative and not restrictive. Many other embodiments will be apparent~to those of skill in the art upon reviewing the above description. For instance, provisions for shared memory oould~be made, ouch ae with yet another bit table, but the bit tables should then also be shay~d, and all programs which access the aharad memory should correctly maintain the status codes, Also, another example of a monitoring scheme especially suitable for implementation through the above object code expansion would be standard profiling. The scope of the invention should, therefore, be i WO 93/00633 ; . .. ..j ~ . PCT/US92/04672:
determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
Claims (16)
1. A method for inserting new instructions into a computer program between preexisting instructions, said method comprising the steps of:
a) providing an old object code table containing the preexisting instructions;
b) providing a new object code table, an inter-item offset table, a forward index table, and a forward control index table, said tables being for storing items in, said items having locations within said tables;
c) performing the following steps for each preexisting instruction in the old object code table:
i) storing a new code block into the new object code table, said new code block comprising any desired new instructions and the preexisting instruction;
ii) storing the location of the preexisting instruction within the new object code table into the forward index table;
iii) storing the location of the new code block within the new object code table into the forward control index table; and iv) for preexisting instructions which contain an inter-item offset, indicating the offset in the inter-item offset table; and d) for each inter-item offset indicated in the inter-item offset table, updating the inter-item offset, using the forward control index table for inter-item offsets which are for program control transfer, and using the forward index table otherwise.
23a
a) providing an old object code table containing the preexisting instructions;
b) providing a new object code table, an inter-item offset table, a forward index table, and a forward control index table, said tables being for storing items in, said items having locations within said tables;
c) performing the following steps for each preexisting instruction in the old object code table:
i) storing a new code block into the new object code table, said new code block comprising any desired new instructions and the preexisting instruction;
ii) storing the location of the preexisting instruction within the new object code table into the forward index table;
iii) storing the location of the new code block within the new object code table into the forward control index table; and iv) for preexisting instructions which contain an inter-item offset, indicating the offset in the inter-item offset table; and d) for each inter-item offset indicated in the inter-item offset table, updating the inter-item offset, using the forward control index table for inter-item offsets which are for program control transfer, and using the forward index table otherwise.
23a
2. A method for inserting new instructions into a relocatable object file having preexisting instructions, data, and linking and debugging auxiliary structures having at least some offsets associated with the preexisting instructions and data, said method comprising the steps of:
a) providing an old object code table, a new object code table, an inter-item offset table, a forward index table, and a forward control index table, said tables being for storing items in, said items having locations within said tables;
b) copying the preexisting instructions and data of the object file into the old object code table;
c) performing the following steps for each item in the old object code table:
i) storing a new code block into the new object code table, said new code block comprising any desired new instructions and the item;
ii) storing the location of the item within the new object code table into the forward index table;
iii) storing the location of the new code block within the new object code table into the forward control index table; and iv) for items which contain an inter-item offset pointing to a target and referenced from a base, indicating in the inter-item offset table the locations of the target and base within the old object code table and of the offset in the new object code table, and modifying the item, if necessary, to be consistent with a maximum-byte offset;
d) for each inter-item offset indicated in the inter-item offset table, determining a forward location for the base using the forward index table, determining a forward location for the target using the forward control index table for targets which are program control transfer destinations and using the forward index table otherwise, and updating the inter-item offset in the new object code table using the forward locations of the base and target;
e) updating the offsets in the auxiliary structures;
and f) creating a new relocatable object file comprising the new object code table and the updated auxiliary structures
a) providing an old object code table, a new object code table, an inter-item offset table, a forward index table, and a forward control index table, said tables being for storing items in, said items having locations within said tables;
b) copying the preexisting instructions and data of the object file into the old object code table;
c) performing the following steps for each item in the old object code table:
i) storing a new code block into the new object code table, said new code block comprising any desired new instructions and the item;
ii) storing the location of the item within the new object code table into the forward index table;
iii) storing the location of the new code block within the new object code table into the forward control index table; and iv) for items which contain an inter-item offset pointing to a target and referenced from a base, indicating in the inter-item offset table the locations of the target and base within the old object code table and of the offset in the new object code table, and modifying the item, if necessary, to be consistent with a maximum-byte offset;
d) for each inter-item offset indicated in the inter-item offset table, determining a forward location for the base using the forward index table, determining a forward location for the target using the forward control index table for targets which are program control transfer destinations and using the forward index table otherwise, and updating the inter-item offset in the new object code table using the forward locations of the base and target;
e) updating the offsets in the auxiliary structures;
and f) creating a new relocatable object file comprising the new object code table and the updated auxiliary structures
3. A method for inserting new instructions into a relocatable object file having preexisting instructions, data, and auxiliary structures, said auxiliary structures having at least some offsets and comprising text relocation structures, data relocation structures, and symbol structures, said method comprising the steps of:
a) providing an entry point table, a new object code table, an inter-item offset table, a forward index table, and a forward control index table, said tables being for storing items in, said items having locations within said tables;
b) providing an old object code table containing the preexisting instructions and data of the object file;
c) for each symbol structure associated with a function and having a function entry address, storing the function entry address in the entry point table, said entry address indicating in the old object code table a first instruction of the function, the function also having a last instruction, all items between the first instruction and last instruction also being instructions of the function;
d) performing the following steps for each entry address stored in the entry point table:
i) performing the following steps for each preexisting instruction of the function indicated by the entry address:
1) storing a new code block into the new object code table, said new code block comprising any desired new instructions and the preexisting instruction;
2) storing the location of the preexisting instruction within the new object code table into the forward index table;
3) storing the location of the new code block within the new object code table into the forward control index table; and 4) for preexisting instructions that contain an inter-item offset pointing to a target and referenced from a base, indicating in the inter-item offset table the locations of the target and base within the old object code table and of the offset in the new object code table, and modifying the preexisting instruction in the new code block, if necessary, to be consistent with a maximum-byte offset; and ii) performing the following steps for each item in the old object code table after the last preexisting instruction of the function indicated by the entry address and before a closest next entry address:
1) copying the item into the new object code table;
2) storing the location of the item within the new object code table into the forward index table;
e) for each inter-item offset indicated in the inter-item offset table, determining a forward location for the base using the forward index table, determining a forward location for the target using the forward control index table for targets which are program control transfer destinations and using the forward index table otherwise, and updating the inter-item offset in the new object code table using the forward locations of the base and target;
f) updating offsets in the auxiliary structures; and g) creating a new relocatable object file comprising the new object code table and the updated auxiliary structures.
a) providing an entry point table, a new object code table, an inter-item offset table, a forward index table, and a forward control index table, said tables being for storing items in, said items having locations within said tables;
b) providing an old object code table containing the preexisting instructions and data of the object file;
c) for each symbol structure associated with a function and having a function entry address, storing the function entry address in the entry point table, said entry address indicating in the old object code table a first instruction of the function, the function also having a last instruction, all items between the first instruction and last instruction also being instructions of the function;
d) performing the following steps for each entry address stored in the entry point table:
i) performing the following steps for each preexisting instruction of the function indicated by the entry address:
1) storing a new code block into the new object code table, said new code block comprising any desired new instructions and the preexisting instruction;
2) storing the location of the preexisting instruction within the new object code table into the forward index table;
3) storing the location of the new code block within the new object code table into the forward control index table; and 4) for preexisting instructions that contain an inter-item offset pointing to a target and referenced from a base, indicating in the inter-item offset table the locations of the target and base within the old object code table and of the offset in the new object code table, and modifying the preexisting instruction in the new code block, if necessary, to be consistent with a maximum-byte offset; and ii) performing the following steps for each item in the old object code table after the last preexisting instruction of the function indicated by the entry address and before a closest next entry address:
1) copying the item into the new object code table;
2) storing the location of the item within the new object code table into the forward index table;
e) for each inter-item offset indicated in the inter-item offset table, determining a forward location for the base using the forward index table, determining a forward location for the target using the forward control index table for targets which are program control transfer destinations and using the forward index table otherwise, and updating the inter-item offset in the new object code table using the forward locations of the base and target;
f) updating offsets in the auxiliary structures; and g) creating a new relocatable object file comprising the new object code table and the updated auxiliary structures.
4. A method of modifying a computer program to have the ability to monitor most of its own memory accesses, said computer program having preexisting code items, said method comprising the steps of a) for most preexisting code items the performance of which involves a memory read, adding memory read monitoring code located so that it will be executed each time the memory read preexisting code item is executed; and b) for most preexisting code items the performance of which involves a memory write, adding memory write monitoring code located so that it will be executed each time the memory write preexisting code item is executed.
5. The method of claim 4, wherein the computer program has a structured representation constructed by a compiler, and wherein a) preexisting code items the performance of which involves a memory read or a memory write are identified by examining the structured representation;
and b) said structured representation is augmented to include the memory read monitoring code and the memory write monitoring code.
and b) said structured representation is augmented to include the memory read monitoring code and the memory write monitoring code.
6. A method for modifying a computer program to have the ability to monitor most of its own memory accesses, wherein memory access types include read and write, said method comprising the steps of:
performing the following steps for substantially all relocatable object files for the program, said relocatable object files containing instruction items of preexisting object code, said instruction items having locations within the preexisting object code:
a) providing a new object code table for storing items in;
b) storing, for each instruction item in the preexisting object code, a new code block into the new object code table, said new code block comprising the item and i) memory read monitoring code for items the performance of which involves a memory access of a read type; and ii) memory write monitoring code for items the performance of which involves a memory access of a write type;
c) updating offsets in the new object code table;
d) creating a new relocatable object file comprising the code items from the new object code file.
performing the following steps for substantially all relocatable object files for the program, said relocatable object files containing instruction items of preexisting object code, said instruction items having locations within the preexisting object code:
a) providing a new object code table for storing items in;
b) storing, for each instruction item in the preexisting object code, a new code block into the new object code table, said new code block comprising the item and i) memory read monitoring code for items the performance of which involves a memory access of a read type; and ii) memory write monitoring code for items the performance of which involves a memory access of a write type;
c) updating offsets in the new object code table;
d) creating a new relocatable object file comprising the code items from the new object code file.
7. The method of claim 6, wherein said computer program is capable of accessing a set of memory regions, said method further comprising the step of adding code to establish memory access status information for substantially all memory locations in the set of accessible memory regions, said status information indicating three states of dynamically allocated memory, said states being allocated-and-initialized, allocated-and-uninitialized, and unallocated; and wherein the storing step comprises i) adding allocation indicating code for items the performance of which would involve allocating memory, said code updating the status information for the allocated memory to be in the allocated-and-unitialized state;
ii) adding deallocation indicating code for items the performance of which would involve deallocating memory, said code updating the status information for the allocated memory to be in the unallocated state;
iii) for adding memory read monitoring code, adding code to signal an error if the accessed memory is not in the allocated-and-initialized state;
iv) for adding memory write monitoring code, adding code signalling an error if the accessed memory is in the unallocated state, otherwise updating the status information for the allocated memory to be in the allocated-and-initialized state if the accessed memory is not in the unallocated state.
ii) adding deallocation indicating code for items the performance of which would involve deallocating memory, said code updating the status information for the allocated memory to be in the unallocated state;
iii) for adding memory read monitoring code, adding code to signal an error if the accessed memory is not in the allocated-and-initialized state;
iv) for adding memory write monitoring code, adding code signalling an error if the accessed memory is in the unallocated state, otherwise updating the status information for the allocated memory to be in the allocated-and-initialized state if the accessed memory is not in the unallocated state.
8. A computer implemented method for producing a set of modified machine instructions from a set of preexisting machine instructions, said set of modified machine instructions having the ability to maintain memory status information for a region of memory and having the ability to check memory accesses to said region of memory, said set of preexisting machine instructions corresponding to a set of preexisting memory accesses to region of memory, said memory status information indicating at least two memory states, said at least two memory states including an allocated state and an unallocated state, said allocated state corresponding to a memory location allocated by a computer program, and said unallocated state corresponding to a memory location not allocated by said computer program, said method comprising the steps of:
providing in a computer storage medium, status information maintenance machine instructions, wherein at least a first portion of said status information maintenance machine instructions is for being executed in conjunction with memory allocation code, and for updating to said allocation state said status information for memory allocated within said memory region by said memory allocation code, and at least a second portion of said status information maintenance machine instructions is for being executed in conjunction with memory deallocation code, and for updating to said unallocated state said status information for memory deallocated within said memory region by said memory deallocation code;
providing, in a computer storage medium, memory access checking machine instructions for being executed in conjunction with a memory access instruction, for checking said status information for memory within said memory region accessed by said memory access instruction and for reporting an error if said status information for said accessed memory indicates said unallocated state;
and modifying said set of preexisting machine instructions to produce in a computer storage medium said modified set of machine instructions including said status information maintenance machine instructions, said memory access checking machine instructions, and instructions corresponding to at least a subset of said set of preexisting machine instructions.
providing in a computer storage medium, status information maintenance machine instructions, wherein at least a first portion of said status information maintenance machine instructions is for being executed in conjunction with memory allocation code, and for updating to said allocation state said status information for memory allocated within said memory region by said memory allocation code, and at least a second portion of said status information maintenance machine instructions is for being executed in conjunction with memory deallocation code, and for updating to said unallocated state said status information for memory deallocated within said memory region by said memory deallocation code;
providing, in a computer storage medium, memory access checking machine instructions for being executed in conjunction with a memory access instruction, for checking said status information for memory within said memory region accessed by said memory access instruction and for reporting an error if said status information for said accessed memory indicates said unallocated state;
and modifying said set of preexisting machine instructions to produce in a computer storage medium said modified set of machine instructions including said status information maintenance machine instructions, said memory access checking machine instructions, and instructions corresponding to at least a subset of said set of preexisting machine instructions.
9. The computer implemented method of claim 8, wherein said step of providing said status information maintenance machine instructions comprises providing status information maintenance machine instructions for maintaining at least a portion of said memory status information in a table having entries indexed by memory address.
10. The computer implemented method of claim,8, wherein said step of providing said status information maintenance machine instructions comprises providing status information maintenance machine instructions for storing any of a first predetermined set of bit patterns in memory allocated by said memory allocation code, and for storing any of a second predetermined set of bit patterns in memory deallocated by said memory deallocation code.
11. The computer implemented method of claim 8, wherein memory access types include read and write, wherein said allocated state further includes an allocated-and-initialized state and an allocated-and-uninitialized state, said allocated-and-initialized state corresponding to a memory location allocated by said computer program and initialized by having data for said computer program but not having data for said computer program written thereto, said at least some preexisting memory access instructions including a set of memory write instructions, for which performance would involve a write access to memory, said at least some preexisting memory access instructions further including a set of memory read instructions, for which performance would involve a read access to memory, wherein said step of providing memory access checking code comprises:
providing memory write checking machine instructions for updating said status information, for memory in said memory region and accessed by a memory write instruction, from said unallocated state to said allocated-and-initialized state, and providing memory read checking machine instructions for signalling an error when memory in said memory region and accessed by a memory read instruction is not in said allocated-and-initialized state; and said step of modifying said set of preexisting machine instructions further comprises:
for each memory write instruction of said set of memory write instructions, said each memory write instruction corresponding to a memory write access, modifying said set of preexisting machine instructions to execute said memory write checking machine instructions when said memory write access is performed, and for each memory read instruction of said set of memory read instructions, said each memory read instruction corresponding to a memory read access, modifying said set of preexisting machine instructions to execute said memory read checking machine instructions when said memory read access is performed.
providing memory write checking machine instructions for updating said status information, for memory in said memory region and accessed by a memory write instruction, from said unallocated state to said allocated-and-initialized state, and providing memory read checking machine instructions for signalling an error when memory in said memory region and accessed by a memory read instruction is not in said allocated-and-initialized state; and said step of modifying said set of preexisting machine instructions further comprises:
for each memory write instruction of said set of memory write instructions, said each memory write instruction corresponding to a memory write access, modifying said set of preexisting machine instructions to execute said memory write checking machine instructions when said memory write access is performed, and for each memory read instruction of said set of memory read instructions, said each memory read instruction corresponding to a memory read access, modifying said set of preexisting machine instructions to execute said memory read checking machine instructions when said memory read access is performed.
12. The computer implemented method of claim 11, wherein said step of providing said status information maintenance machine instructions comprises providing status information maintenance machine instructions for maintaining at least a portion of said memory status information in a table having entries indexed by memory address.
13. The method of claim 11, wherein said step of providing said memory access checking machine instructions comprises providing memory access checking machine instructions for checking for at least some of said status information as a predetermined bit pattern stored in said accessed memory.
14. A computer implemented method for producing a set of modified machine instructions from a set of preexisting machine instructions, said set of modified machine instructions having the ability to maintain memory status information for a region of memory and having the ability to check memory accesses to said region of memory, said set of preexisting machine instructions comprising a set of preexisting memory access instructions corresponding to a set of preexisting memory accesses, said set of preexisting memory access instructions comprising a first group of at least some memory write instructions, for which performance would involve a write access to memory, said set of preexisting memory access instructions further comprising a second group of at least some memory read instructions, for which performance would involve a read access to memory, said memory status information indicating at least two memory states, said at least two states including an initialized state and an uninitialized state, said initialized state corresponding to a memory location initialized by having data for a computer program written thereto, said uninitialized state corresponding to a memory location not having data for said computer program written thereto, said method comprising the steps of:
providing, in a computer storage medium, memory write monitoring machine instructions for updating said status information, for memory in said memory region and accessed by a memory write instruction, from said uninitialized state to said initialized state;
providing, in a computer storage medium, memory read checking machine instructions for signalling an error when memory, in said memory region and accessed by a memory read instruction, is not in said initialized state;
modifying said set of preexisting machine instructions to produce in a computer storage medium said modified set of machine instructions, by for each said memory write instruction, corresponding to a memory write access, modifying said set of preexisting machine instructions to execute said memory write monitoring machine instructions when said memory write access is performed, and for each said memory read instruction, corresponding to a memory read access, modifying said set of preexisting machine instructions to execute said memory read checking machine instructions when said memory read access is performed.
providing, in a computer storage medium, memory write monitoring machine instructions for updating said status information, for memory in said memory region and accessed by a memory write instruction, from said uninitialized state to said initialized state;
providing, in a computer storage medium, memory read checking machine instructions for signalling an error when memory, in said memory region and accessed by a memory read instruction, is not in said initialized state;
modifying said set of preexisting machine instructions to produce in a computer storage medium said modified set of machine instructions, by for each said memory write instruction, corresponding to a memory write access, modifying said set of preexisting machine instructions to execute said memory write monitoring machine instructions when said memory write access is performed, and for each said memory read instruction, corresponding to a memory read access, modifying said set of preexisting machine instructions to execute said memory read checking machine instructions when said memory read access is performed.
15. The computer implemented method of claim 8,9, 10, 11, 12, 13 or 14, wherein said set of modified machine instructions are in relocatable machine instruction format, said step of modifying said set of preexisting machine instructions further comprising the steps of linking a set of relocatable object files with said set of modified machine instructions to form an executable computer program; and executing said executable computer program.
16. The computer implemented method of claim 8, 9, 10, 11, 12, 13 or 14, wherein said set of preexisting machine instructions and said set of modified machine instructions are in executable machine instruction format, wherein an executable computer program comprises said set of modified machine instructions, said method further comprising the step of executing said executable computer program.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CA002426712A CA2426712A1 (en) | 1991-06-21 | 1992-06-05 | Method for signaling errors in memory accesses by a computer program |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US718,573 | 1991-06-21 | ||
US07/718,573 US5193180A (en) | 1991-06-21 | 1991-06-21 | System for modifying relocatable object code files to monitor accesses to dynamically allocated memory |
PCT/US1992/004672 WO1993000633A1 (en) | 1991-06-21 | 1992-06-05 | Method and apparatus for modifying relocatable object code files and monitoring programs |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA002426712A Division CA2426712A1 (en) | 1991-06-21 | 1992-06-05 | Method for signaling errors in memory accesses by a computer program |
Publications (2)
Publication Number | Publication Date |
---|---|
CA2111958A1 CA2111958A1 (en) | 1993-01-07 |
CA2111958C true CA2111958C (en) | 2003-08-05 |
Family
ID=24886584
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA002111958A Expired - Fee Related CA2111958C (en) | 1991-06-21 | 1992-06-05 | Method and apparatus for modifying relocatable object code files and monitoring programs |
Country Status (6)
Country | Link |
---|---|
US (7) | US5193180A (en) |
EP (1) | EP0591360B1 (en) |
AU (1) | AU2188792A (en) |
CA (1) | CA2111958C (en) |
DE (1) | DE69232761T2 (en) |
WO (1) | WO1993000633A1 (en) |
Families Citing this family (393)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0816877B2 (en) * | 1991-06-10 | 1996-02-21 | インターナショナル・ビジネス・マシーンズ・コーポレイション | Method and system for real-time capture and reduction of resource data for data processing system |
US5193180A (en) | 1991-06-21 | 1993-03-09 | Pure Software Inc. | System for modifying relocatable object code files to monitor accesses to dynamically allocated memory |
US5446899A (en) * | 1992-06-26 | 1995-08-29 | Digital Equipment Corporation | Hint generation in smart recompilation |
US5625822A (en) * | 1992-06-26 | 1997-04-29 | Digital Equipment Corporation | Using sorting to do matchup in smart recompilation |
US5535392A (en) * | 1992-06-26 | 1996-07-09 | Digital Equipment Corporation | Using hint generation to cause portions of object files to remain the same |
US5367683A (en) * | 1992-06-26 | 1994-11-22 | Digital Equipment Corporation | Smart recompilation of performing matchup/difference after code generation |
JPH06103075A (en) * | 1992-07-06 | 1994-04-15 | Internatl Business Mach Corp <Ibm> | Operation for object-oriented application |
US5685003A (en) * | 1992-12-23 | 1997-11-04 | Microsoft Corporation | Method and system for automatically indexing data in a document using a fresh index table |
US5559980A (en) * | 1993-03-18 | 1996-09-24 | Lucent Technologies Inc. | Method and apparatus for detecting references to deallocated memory in a dynamic memory allocation system |
US6219830B1 (en) * | 1993-03-23 | 2001-04-17 | Apple Computer, Inc. | Relocatable object code format and method for loading same into a computer system |
WO1994022078A2 (en) * | 1993-03-23 | 1994-09-29 | Apple Computer, Inc. | Apparatus and method for a relocatable file format |
US6151701A (en) * | 1997-09-30 | 2000-11-21 | Ahpah Software, Inc. | Method for reconstructing debugging information for a decompiled executable file |
US5481713A (en) * | 1993-05-06 | 1996-01-02 | Apple Computer, Inc. | Method and apparatus for patching code residing on a read only memory device |
US5546586A (en) * | 1993-05-06 | 1996-08-13 | Apple Computer, Inc. | Method and apparatus for vectorizing the contents of a read only memory device without modifying underlying source code |
JPH06332680A (en) * | 1993-05-21 | 1994-12-02 | Tadao Shogetsu | Automatic program generation device |
CA2097540C (en) * | 1993-06-01 | 1998-05-12 | William G. O'farrell | Accessing remote data objects in a distributed memory environment |
US6126329A (en) | 1993-06-08 | 2000-10-03 | Rational Software Coporation | Method and apparatus for accurate profiling of computer programs |
US5408650A (en) * | 1993-06-29 | 1995-04-18 | Digital Equipment Corporation | Memory analysis system for dynamically displaying memory allocation and de-allocation events associated with an application program |
DE4334313A1 (en) * | 1993-10-08 | 1995-04-13 | Sel Alcatel Ag | Method for managing a voice memory and device therefor |
US6263488B1 (en) | 1993-12-03 | 2001-07-17 | International Business Machines Corporation | System and method for enabling software monitoring in a computer system |
US5596713A (en) * | 1993-12-08 | 1997-01-21 | Zenith Data Systems Corporation | Method to prevent data loss in an electrically erasable read only memory |
US5729676A (en) * | 1993-12-10 | 1998-03-17 | Nec Corporation | Method of generating data for evaluating programs |
US5581697A (en) * | 1994-01-28 | 1996-12-03 | Sun Microsystems, Inc. | Method and apparatus for run-time error checking using dynamic patching |
US5675803A (en) * | 1994-01-28 | 1997-10-07 | Sun Microsystems, Inc. | Method and apparatus for a fast debugger fix and continue operation |
US5590329A (en) * | 1994-02-04 | 1996-12-31 | Lucent Technologies Inc. | Method and apparatus for detecting memory access errors |
US5604895A (en) * | 1994-02-22 | 1997-02-18 | Motorola Inc. | Method and apparatus for inserting computer code into a high level language (HLL) software model of an electrical circuit to monitor test coverage of the software model when exposed to test inputs |
US5539907A (en) * | 1994-03-01 | 1996-07-23 | Digital Equipment Corporation | System for monitoring computer system performance |
US5583988A (en) * | 1994-03-09 | 1996-12-10 | National Instruments Corporation | Method and apparatus for providing runtime checking features in a compiled programming development environment |
US5644709A (en) * | 1994-04-21 | 1997-07-01 | Wisconsin Alumni Research Foundation | Method for detecting computer memory access errors |
JP2757777B2 (en) * | 1994-05-26 | 1998-05-25 | 住友金属工業株式会社 | Method and system for detecting unauthorized access to memory |
US5528753A (en) * | 1994-06-30 | 1996-06-18 | International Business Machines Corporation | System and method for enabling stripped object software monitoring in a computer system |
US5613063A (en) * | 1994-07-01 | 1997-03-18 | Digital Equipment Corporation | Method and apparatus for checking validity of memory operations |
US5689712A (en) * | 1994-07-27 | 1997-11-18 | International Business Machines Corporation | Profile-based optimizing postprocessors for data references |
US5694539A (en) * | 1994-08-10 | 1997-12-02 | Intrinsa Corporation | Computer process resource modelling method and apparatus |
US6006033A (en) * | 1994-08-15 | 1999-12-21 | International Business Machines Corporation | Method and system for reordering the instructions of a computer program to optimize its execution |
US5542078A (en) * | 1994-09-29 | 1996-07-30 | Ontos, Inc. | Object oriented data store integration environment for integration of object oriented databases and non-object oriented data facilities |
US5621912A (en) * | 1994-12-29 | 1997-04-15 | International Business Machines Corporation | Method and apparatus for enabling monitoring of guests and native operating systems |
EP0729097A1 (en) * | 1995-02-07 | 1996-08-28 | Sun Microsystems, Inc. | Method and apparatus for run-time memory access checking and memory leak detection of a multi-threaded program |
US5710724A (en) * | 1995-04-20 | 1998-01-20 | Digital Equipment Corp. | Dynamic computer performance monitor |
US5619698A (en) * | 1995-05-05 | 1997-04-08 | Apple Computer, Inc. | Method and apparatus for patching operating systems |
US5787447A (en) * | 1995-05-08 | 1998-07-28 | Sun Microsystems, Inc. | Memory allocation maintaining ordering across multiple heaps |
US5812828A (en) * | 1995-06-01 | 1998-09-22 | Centerline Software, Inc. | Function simulation |
CA2224689C (en) * | 1995-06-02 | 2002-10-29 | Rational Software Corporation | Remote monitoring of computer programs |
US5867701A (en) * | 1995-06-12 | 1999-02-02 | Intel Corporation | System for inserting a supplemental micro-operation flow into a macroinstruction-generated micro-operation flow |
US5778169A (en) * | 1995-08-07 | 1998-07-07 | Synopsys, Inc. | Computer system having improved regression testing |
US6021272A (en) * | 1995-10-04 | 2000-02-01 | Platinum Technology, Inc. | Transforming and manipulating program object code |
FI103155B1 (en) | 1995-10-11 | 1999-04-30 | Nokia Telecommunications Oy | Procedure for providing computer controlled service |
WO1997014096A1 (en) * | 1995-10-13 | 1997-04-17 | Sevone Software, Inc. | System and method for debugging computer software |
EP0778524A1 (en) * | 1995-11-17 | 1997-06-11 | Nec Corporation | Method and device for evaluating a program |
US5802265A (en) * | 1995-12-01 | 1998-09-01 | Stratus Computer, Inc. | Transparent fault tolerant computer system |
US5758061A (en) * | 1995-12-15 | 1998-05-26 | Plum; Thomas S. | Computer software testing method and apparatus |
US6085233A (en) * | 1995-12-29 | 2000-07-04 | Pankosmion, Inc. | System and method for cellular network computing and communications |
US5907709A (en) * | 1996-02-08 | 1999-05-25 | Inprise Corporation | Development system with methods for detecting invalid use and management of resources and memory at runtime |
US5909580A (en) * | 1996-02-08 | 1999-06-01 | Inprise Corporation | Development system and methods with direct compiler support for detecting invalid use and management of resources and memory at runtime |
US6128771A (en) * | 1996-02-09 | 2000-10-03 | Sun Microsystems, Inc. | System and method for automatically modifying database access methods to insert database object handling instructions |
US5875318A (en) * | 1996-04-12 | 1999-02-23 | International Business Machines Corporation | Apparatus and method of minimizing performance degradation of an instruction set translator due to self-modifying code |
US5978892A (en) * | 1996-05-03 | 1999-11-02 | Digital Equipment Corporation | Virtual memory allocation in a virtual address space having an inaccessible gap |
US5761729A (en) * | 1996-07-17 | 1998-06-02 | Digital Equipment Corporation | Validation checking of shared memory accesses |
US5802585A (en) * | 1996-07-17 | 1998-09-01 | Digital Equipment Corporation | Batched checking of shared memory accesses |
US5787480A (en) * | 1996-07-17 | 1998-07-28 | Digital Equipment Corporation | Lock-up free data sharing |
US5848275A (en) * | 1996-07-29 | 1998-12-08 | Silicon Graphics, Inc. | Compiler having automatic common blocks of memory splitting |
US5949972A (en) * | 1996-08-23 | 1999-09-07 | Compuware Corporation | System for memory error checking in an executable |
US6186677B1 (en) | 1996-08-27 | 2001-02-13 | Compuware Corporation | Byte code instrumentation |
US6701519B1 (en) * | 2000-04-12 | 2004-03-02 | Compuware Corporation | Managing hardware and software configuration information of systems being tested |
US5987249A (en) * | 1996-08-27 | 1999-11-16 | Numega Technologies | IR code instrumentation |
US5870607A (en) * | 1996-09-11 | 1999-02-09 | Brown University Research Foundation | Method and apparatus for selective replay of computer programs |
US6513154B1 (en) | 1996-10-21 | 2003-01-28 | John R. Porterfield | System and method for testing of computer programs in programming effort |
US5923878A (en) * | 1996-11-13 | 1999-07-13 | Sun Microsystems, Inc. | System, method and apparatus of directly executing an architecture-independent binary program |
US6141698A (en) * | 1997-01-29 | 2000-10-31 | Network Commerce Inc. | Method and system for injecting new code into existing application code |
US6654879B1 (en) * | 1997-01-30 | 2003-11-25 | Northbrook Services | Method and apparatus for analyzing code for out-of-range data involving base and seed tables/lists |
US6009269A (en) * | 1997-03-10 | 1999-12-28 | Digital Equipment Corporation | Detecting concurrency errors in multi-threaded programs |
US5950009A (en) * | 1997-03-10 | 1999-09-07 | International Business Machines Coporation | Method and apparatus for profile-based reordering of program portions in a computer program |
US6029004A (en) * | 1997-03-17 | 2000-02-22 | International Business Machines Corporation | Method and apparatus for modular reordering of portions of a computer program based on profile data |
US5982807A (en) | 1997-03-17 | 1999-11-09 | Harris Corporation | High data rate spread spectrum transceiver and associated methods |
US6026234A (en) * | 1997-03-19 | 2000-02-15 | International Business Machines Corporation | Method and apparatus for profiling indirect procedure calls in a computer program |
US5960198A (en) * | 1997-03-19 | 1999-09-28 | International Business Machines Corporation | Software profiler with runtime control to enable and disable instrumented executable |
US6631518B1 (en) * | 1997-03-19 | 2003-10-07 | International Business Machines Corporation | Generating and utilizing organized profile information |
US5974249A (en) * | 1997-03-24 | 1999-10-26 | Symantec Corporation | Zero footprint method and apparatus for expanding allocated memory space of a process using a virtual memory area |
US5898850A (en) * | 1997-03-31 | 1999-04-27 | International Business Machines Corporation | Method and system for executing a non-native mode-sensitive instruction within a computer system |
US6073256A (en) * | 1997-04-11 | 2000-06-06 | Preview Systems, Inc. | Digital product execution control |
US6272636B1 (en) | 1997-04-11 | 2001-08-07 | Preview Systems, Inc | Digital product execution control and security |
US6149318A (en) * | 1997-04-15 | 2000-11-21 | Samuel C. Kendall | Link-time and run-time error detection, and program instrumentation |
US5948113A (en) * | 1997-04-18 | 1999-09-07 | Microsoft Corporation | System and method for centrally handling runtime errors |
US5915255A (en) * | 1997-04-23 | 1999-06-22 | Sun Microsystems, Inc. | Method and apparatus for referencing nodes using links |
US5911144A (en) * | 1997-04-23 | 1999-06-08 | Sun Microsystems, Inc. | Method and apparatus for optimizing the assignment of hash values to nodes residing in a garbage collected heap |
US6101580A (en) * | 1997-04-23 | 2000-08-08 | Sun Microsystems, Inc. | Apparatus and method for assisting exact garbage collection by using a stack cache of tag bits |
US5848423A (en) * | 1997-04-23 | 1998-12-08 | Sun Microsystems, Inc. | Garbage collection system and method for locating root set pointers in method activation records |
US5903900A (en) * | 1997-04-23 | 1999-05-11 | Sun Microsystems, Inc. | Method and apparatus for optimizing exact garbage collection of array nodes in a carded heap |
US5909579A (en) * | 1997-04-23 | 1999-06-01 | Sun Microsystems, Inc. | Method and apparatus for encoding and decoding delta encoded information to locate live pointers in program data stacks |
US6038572A (en) * | 1997-04-23 | 2000-03-14 | Sun Microsystems, Inc. | Method and apparatus for localizing nodes in a garbage collected carded heap |
US5893121A (en) * | 1997-04-23 | 1999-04-06 | Sun Microsystems, Inc. | System and method for swapping blocks of tagged stack entries between a tagged stack cache and an untagged main memory storage |
US5900001A (en) * | 1997-04-23 | 1999-05-04 | Sun Microsystems, Inc. | Method and apparatus for optimizing exact garbage collection using a bifurcated data structure |
US5930807A (en) * | 1997-04-23 | 1999-07-27 | Sun Microsystems | Apparatus and method for fast filtering read and write barrier operations in garbage collection system |
US5920876A (en) * | 1997-04-23 | 1999-07-06 | Sun Microsystems, Inc. | Performing exact garbage collection using bitmaps that identify pointer values within objects |
US5903899A (en) * | 1997-04-23 | 1999-05-11 | Sun Microsystems, Inc. | System and method for assisting exact Garbage collection by segregating the contents of a stack into sub stacks |
US6115782A (en) * | 1997-04-23 | 2000-09-05 | Sun Micosystems, Inc. | Method and apparatus for locating nodes in a carded heap using a card marking structure and a node advance value |
US6199075B1 (en) | 1997-05-30 | 2001-03-06 | Sun Microsystems, Inc. | Method and apparatus for generational garbage collection of a heap memory shared by multiple processors |
US6094664A (en) * | 1997-05-30 | 2000-07-25 | Sun Microsystems | Method and apparatus for optimizing the null pointer exception in an object-oriented programming environment with statically typed variables |
US5983337A (en) * | 1997-06-12 | 1999-11-09 | Advanced Micro Devices, Inc. | Apparatus and method for patching an instruction by providing a substitute instruction or instructions from an external memory responsive to detecting an opcode of the instruction |
US5937402A (en) * | 1997-06-19 | 1999-08-10 | Ontos, Inc. | System for enabling access to a relational database from an object oriented program |
US6105040A (en) * | 1997-06-30 | 2000-08-15 | Sun Microsystems, Inc. | Method and apparatus for managing stored objects |
US5953531A (en) * | 1997-07-25 | 1999-09-14 | International Business Machines Corporation | Method of, system for, and computer program product for minimizing loop execution time by optimizing block/tile sizes |
US6282701B1 (en) * | 1997-07-31 | 2001-08-28 | Mutek Solutions, Ltd. | System and method for monitoring and analyzing the execution of computer programs |
US6286130B1 (en) | 1997-08-05 | 2001-09-04 | Intel Corporation | Software implemented method for automatically validating the correctness of parallel computer programs |
JPH1185526A (en) * | 1997-09-12 | 1999-03-30 | Hitachi Ltd | Program loading method |
US6012065A (en) * | 1997-09-30 | 2000-01-04 | Pitney Bowes Inc. | Method and system for accessing carrier data |
US6047125A (en) | 1997-10-01 | 2000-04-04 | Sun Microsystems, Inc. | Garbage collection system for improved use of memory by removal of reference conflicts |
US6910047B1 (en) | 1997-10-01 | 2005-06-21 | Pitney Bowes Inc. | Method and system for changing rating data via internet or modem in a carrier management system |
US6873978B1 (en) | 1997-10-01 | 2005-03-29 | Pitney Bowes Inc. | Event interface for a carrier manager system |
WO1999039261A1 (en) * | 1997-10-09 | 1999-08-05 | The Learning Company | Windows api trapping system |
US6321376B1 (en) * | 1997-10-27 | 2001-11-20 | Ftl Systems, Inc. | Apparatus and method for semi-automated generation and application of language conformity tests |
US6128774A (en) * | 1997-10-28 | 2000-10-03 | Necula; George C. | Safe to execute verification of software |
WO1999022288A2 (en) * | 1997-10-29 | 1999-05-06 | Geodesic Systems, Inc. | Interactive debugging system with debug data base system |
US6938245B1 (en) | 1997-10-29 | 2005-08-30 | Veritas Operating Corporation | Interactive debugging system with debug data base system |
US5949993A (en) * | 1997-10-31 | 1999-09-07 | Production Languages Corporation | Method for the generation of ISA simulators and assemblers from a machine description |
US6314564B1 (en) | 1997-11-17 | 2001-11-06 | Agere Systems Guardian Corp. | Method for resolving arbitrarily complex expressions at link-time |
US6560773B1 (en) * | 1997-12-12 | 2003-05-06 | International Business Machines Corporation | Method and system for memory leak detection in an object-oriented environment during real-time trace processing |
US6338159B1 (en) * | 1997-12-12 | 2002-01-08 | International Business Machines Corporation | System and method for providing trace information |
US5911073A (en) * | 1997-12-23 | 1999-06-08 | Hewlett-Packard Company | Method and apparatus for dynamic process monitoring through an ancillary control code system |
US6334213B1 (en) | 1998-01-20 | 2001-12-25 | Preview Systems | Merging of separate executable computer programs to form a single executable computer program |
US6505212B2 (en) | 1998-02-04 | 2003-01-07 | Interwoven Inc | System and method for website development |
JP3178403B2 (en) * | 1998-02-16 | 2001-06-18 | 日本電気株式会社 | Program conversion method, program conversion device, and storage medium storing program conversion program |
US6230316B1 (en) * | 1998-04-17 | 2001-05-08 | Symantec Corporation | Patching rebased and realigned executable files |
US6343375B1 (en) * | 1998-04-24 | 2002-01-29 | International Business Machines Corporation | Method for optimizing array bounds checks in programs |
US6164841A (en) * | 1998-05-04 | 2000-12-26 | Hewlett-Packard Company | Method, apparatus, and product for dynamic software code translation system |
US6148437A (en) * | 1998-05-04 | 2000-11-14 | Hewlett-Packard Company | System and method for jump-evaluated trace designation |
US6189141B1 (en) | 1998-05-04 | 2001-02-13 | Hewlett-Packard Company | Control path evaluating trace designator with dynamically adjustable thresholds for activation of tracing for high (hot) activity and low (cold) activity of flow control |
US6230311B1 (en) * | 1998-06-12 | 2001-05-08 | International Business Machines Corporation | Apparatus and method for disabling methods called on an object |
US6216237B1 (en) * | 1998-06-19 | 2001-04-10 | Lucent Technologies Inc. | Distributed indirect software instrumentation |
US6110227A (en) * | 1998-06-24 | 2000-08-29 | Microsoft Corporation | Systems and methods for pre-processing variable initializers |
US6158047A (en) * | 1998-07-08 | 2000-12-05 | Hewlett-Packard Company | Client/server system for fast, user transparent and memory efficient computer language translation |
US7260817B2 (en) * | 1999-07-09 | 2007-08-21 | International Business Machines Corporation | Method using array range check information for generating versioning code before a loop for execution |
JP3280332B2 (en) * | 1998-07-10 | 2002-05-13 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Method and apparatus for performing versioning on loop, method and apparatus for collecting information on array range check in basic block, method for changing information on array range check, method for optimizing array range check, array range Method of generating code for checking, unnecessary array range check removal method and apparatus, method of selecting array range check, method of changing array range check, collection method of array range check, and handling judgment of array range check Method |
US6490721B1 (en) | 1998-07-14 | 2002-12-03 | Oc Systems Incorporated | Software debugging method and apparatus |
US6253215B1 (en) | 1998-08-17 | 2001-06-26 | Sun Microsystems | Method, apparatus, and article of manufacture for facilitating resource management for applications having two types of program code |
IL125846A0 (en) | 1998-08-19 | 1999-04-11 | Emony | Incremental program update |
US6260187B1 (en) | 1998-08-20 | 2001-07-10 | Wily Technology, Inc. | System for modifying object oriented code |
US6223339B1 (en) * | 1998-09-08 | 2001-04-24 | Hewlett-Packard Company | System, method, and product for memory management in a dynamic translator |
US6983463B1 (en) | 1998-10-02 | 2006-01-03 | Microsoft Corporation | Network independent profiling of applications for automatic partitioning and distribution in a distributed computing environment |
US7039919B1 (en) * | 1998-10-02 | 2006-05-02 | Microsoft Corporation | Tools and techniques for instrumenting interfaces of units of a software program |
US6381735B1 (en) | 1998-10-02 | 2002-04-30 | Microsoft Corporation | Dynamic classification of sections of software |
US6988271B2 (en) * | 1998-10-02 | 2006-01-17 | Microsoft Corporation | Heavyweight and lightweight instrumentation |
US6381628B1 (en) | 1998-10-02 | 2002-04-30 | Microsoft Corporation | Summarized application profiling and quick network profiling |
US6499137B1 (en) * | 1998-10-02 | 2002-12-24 | Microsoft Corporation | Reversible load-time dynamic linking |
US6546553B1 (en) | 1998-10-02 | 2003-04-08 | Microsoft Corporation | Service installation on a base function and provision of a pass function with a service-free base function semantic |
US6629123B1 (en) | 1998-10-02 | 2003-09-30 | Microsoft Corporation | Interception of unit creation requests by an automatic distributed partitioning system |
GB9825102D0 (en) * | 1998-11-16 | 1999-01-13 | Insignia Solutions Plc | Computer system |
US6668373B1 (en) * | 1998-11-23 | 2003-12-23 | Willard H. Wattenburg | System, apparatus and method for expanding the range of decimal numbers of any length in existing data bases and computer programs |
US7380245B1 (en) * | 1998-11-23 | 2008-05-27 | Samsung Electronics Co., Ltd. | Technique for detecting corruption associated with a stack in a storage device |
FR2786285B1 (en) * | 1998-11-24 | 2001-02-02 | Secap | DEVICE AND METHOD FOR PROTECTING AGAINST BATTERY OVERFLOWS IN A MEMORY AND FRANKING MACHINE IMPLEMENTING THEM |
US7310718B1 (en) | 1998-11-25 | 2007-12-18 | Sun Microsystems, Inc. | Method for enabling comprehensive profiling of garbage-collected memory systems |
US6332215B1 (en) | 1998-12-08 | 2001-12-18 | Nazomi Communications, Inc. | Java virtual machine hardware for RISC and CISC processors |
US6826749B2 (en) | 1998-12-08 | 2004-11-30 | Nazomi Communications, Inc. | Java hardware accelerator using thread manager |
US20050149694A1 (en) * | 1998-12-08 | 2005-07-07 | Mukesh Patel | Java hardware accelerator using microcode engine |
US7225436B1 (en) | 1998-12-08 | 2007-05-29 | Nazomi Communications Inc. | Java hardware accelerator using microcode engine |
US20020073398A1 (en) * | 1998-12-14 | 2002-06-13 | Jeffrey L. Tinker | Method and system for modifying executable code to add additional functionality |
US7140005B2 (en) * | 1998-12-21 | 2006-11-21 | Intel Corporation | Method and apparatus to test an instruction sequence |
US6336217B1 (en) * | 1998-12-30 | 2002-01-01 | International Business Machines Corporation | Systems, methods and computer program products for end-to-end software development process automation |
US6343297B1 (en) | 1998-12-30 | 2002-01-29 | International Business Machines Corporation | Methods, systems and computer program products for providing document management for software development systems |
JP3355602B2 (en) * | 1999-01-27 | 2002-12-09 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Method and apparatus for processing multidimensional array objects |
US6446257B1 (en) * | 1999-02-04 | 2002-09-03 | Hewlett-Packard Company | Method and apparatus for pre-allocation of system resources to facilitate garbage collection |
US6430741B1 (en) * | 1999-02-26 | 2002-08-06 | Hewlett-Packard Company | System and method for data coverage analysis of a computer program |
US6367071B1 (en) * | 1999-03-02 | 2002-04-02 | Lucent Technologies Inc. | Compiler optimization techniques for exploiting a zero overhead loop mechanism |
US20020135611A1 (en) * | 1999-03-04 | 2002-09-26 | Trevor Deosaran | Remote performance management to accelerate distributed processes |
US6580431B1 (en) | 1999-03-04 | 2003-06-17 | Nexmem | System, method, and computer program product for intelligent memory to accelerate processes |
US6463583B1 (en) * | 1999-04-08 | 2002-10-08 | Novadigm, Inc. | Dynamic injection of execution logic into main dynamic link library function of the original kernel of a windowed operating system |
US6714995B2 (en) * | 1999-07-09 | 2004-03-30 | Bellsouth Intellectual Property Corporation | Method and apparatus for archiving, updating or retrieving an uninitialized entry in an advanced intelligent network |
US7770016B2 (en) * | 1999-07-29 | 2010-08-03 | Intertrust Technologies Corporation | Systems and methods for watermarking software and other media |
US6745385B1 (en) * | 1999-09-01 | 2004-06-01 | Microsoft Corporation | Fixing incompatible applications by providing stubs for APIs |
US7032213B1 (en) * | 1999-09-01 | 2006-04-18 | Microsoft Corporation | Fixing incompatible applications using a light debugger |
GB2358491A (en) * | 1999-09-03 | 2001-07-25 | Sgs Thomson Microelectronics | A relocation format for linking |
GB9920916D0 (en) * | 1999-09-03 | 1999-11-10 | Sgs Thomson Microelectronics | A relocation format for linking |
JP3838825B2 (en) * | 1999-09-27 | 2006-10-25 | 富士通株式会社 | System analysis apparatus and method, and storage medium storing analysis program |
US6766514B1 (en) * | 1999-10-19 | 2004-07-20 | General Electric Co. | Compiler having real-time tuning, I/O scaling and process test capability |
US6438664B1 (en) | 1999-10-27 | 2002-08-20 | Advanced Micro Devices, Inc. | Microcode patch device and method for patching microcode using match registers and patch routines |
US6662310B2 (en) | 1999-11-10 | 2003-12-09 | Symantec Corporation | Methods for automatically locating url-containing or other data-containing windows in frozen browser or other application program, saving contents, and relaunching application program with link to saved data |
US6630946B2 (en) | 1999-11-10 | 2003-10-07 | Symantec Corporation | Methods for automatically locating data-containing windows in frozen applications program and saving contents |
US6631480B2 (en) | 1999-11-10 | 2003-10-07 | Symantec Corporation | Methods and systems for protecting data from potential corruption by a crashed computer program |
US6718485B1 (en) | 1999-11-16 | 2004-04-06 | Parasoft Corporation | Software emulating hardware for analyzing memory references of a computer program |
US6477666B1 (en) * | 1999-11-22 | 2002-11-05 | International Business Machines Corporation | Automatic fault injection into a JAVA virtual machine (JVM) |
US7111307B1 (en) | 1999-11-23 | 2006-09-19 | Microsoft Corporation | Method and system for monitoring and verifying software drivers using system resources including memory allocation and access |
US6817011B1 (en) | 1999-12-14 | 2004-11-09 | International Business Machines Corporation | Memory allocation profiling to discover high frequency allocators |
US7058928B2 (en) | 1999-12-23 | 2006-06-06 | Identify Software Ltd. | System and method for conditional tracing of computer programs |
US7107526B1 (en) * | 2000-01-19 | 2006-09-12 | Xerox Corporation | Transparent injection of specific content into web pages viewed while browsing |
US6550058B1 (en) * | 2000-02-03 | 2003-04-15 | International Business Machines Corporation | Stack clearing device and method |
US6912571B1 (en) * | 2000-02-22 | 2005-06-28 | Frank David Serena | Method of replacing content |
US6578094B1 (en) * | 2000-03-02 | 2003-06-10 | International Business Machines Corporation | Method for preventing buffer overflow attacks |
US20020087949A1 (en) * | 2000-03-03 | 2002-07-04 | Valery Golender | System and method for software diagnostics using a combination of visual and dynamic tracing |
US6634020B1 (en) | 2000-03-24 | 2003-10-14 | International Business Machines Corporation | Uninitialized memory watch |
US6687851B1 (en) | 2000-04-13 | 2004-02-03 | Stratus Technologies Bermuda Ltd. | Method and system for upgrading fault-tolerant systems |
US6820213B1 (en) | 2000-04-13 | 2004-11-16 | Stratus Technologies Bermuda, Ltd. | Fault-tolerant computer system with voter delay buffer |
US6691225B1 (en) | 2000-04-14 | 2004-02-10 | Stratus Technologies Bermuda Ltd. | Method and apparatus for deterministically booting a computer system having redundant components |
US6862689B2 (en) | 2001-04-12 | 2005-03-01 | Stratus Technologies Bermuda Ltd. | Method and apparatus for managing session information |
US6802022B1 (en) | 2000-04-14 | 2004-10-05 | Stratus Technologies Bermuda Ltd. | Maintenance of consistent, redundant mass storage images |
US6901481B2 (en) | 2000-04-14 | 2005-05-31 | Stratus Technologies Bermuda Ltd. | Method and apparatus for storing transactional information in persistent memory |
US6823507B1 (en) | 2000-06-06 | 2004-11-23 | International Business Machines Corporation | Detection of memory-related errors in computer programs |
US6658653B1 (en) * | 2000-06-08 | 2003-12-02 | International Business Machines Corporation | Debugging methods for heap misuse |
US6918106B1 (en) * | 2000-07-31 | 2005-07-12 | Sun Microsystems, Inc. | Method and apparatus for collocating dynamically loaded program files |
EP1197847A3 (en) * | 2000-10-10 | 2003-05-21 | Nazomi Communications Inc. | Java hardware accelerator using microcode engine |
GB0029115D0 (en) * | 2000-11-29 | 2001-01-10 | Sgs Thomson Microelectronics | Assembling an object code module |
US20020129336A1 (en) * | 2000-12-19 | 2002-09-12 | Bolding Joe D. | Automatic symbol table selection in a multi-cell environment |
US6948010B2 (en) * | 2000-12-20 | 2005-09-20 | Stratus Technologies Bermuda Ltd. | Method and apparatus for efficiently moving portions of a memory block |
US7672947B2 (en) * | 2000-12-22 | 2010-03-02 | James H. Kerr, Sr. | Asset attachment device |
US8312435B2 (en) * | 2000-12-26 | 2012-11-13 | Identify Software Ltd. (IL) | System and method for conditional tracing of computer programs |
GB0031750D0 (en) * | 2000-12-28 | 2001-02-07 | Sgs Thomson Microelectronics | Retrieval of symbol attributes |
KR100525537B1 (en) * | 2000-12-28 | 2005-11-02 | 엘지전자 주식회사 | Applied Program Bungle Detection Apparatus and Method by Interrupt |
US20020099872A1 (en) * | 2001-01-19 | 2002-07-25 | Vinodha Ramasamy | Allocating registers for use in programming code modification |
US8458754B2 (en) * | 2001-01-22 | 2013-06-04 | Sony Computer Entertainment Inc. | Method and system for providing instant start multimedia content |
US6957421B2 (en) * | 2001-01-26 | 2005-10-18 | Hewlett-Packard Development Company, L.P. | Providing debugging capability for program instrumented code |
US6886171B2 (en) * | 2001-02-20 | 2005-04-26 | Stratus Technologies Bermuda Ltd. | Caching for I/O virtual address translation and validation using device drivers |
US7225361B2 (en) * | 2001-02-28 | 2007-05-29 | Wily Technology, Inc. | Detecting a stalled routine |
US6766413B2 (en) | 2001-03-01 | 2004-07-20 | Stratus Technologies Bermuda Ltd. | Systems and methods for caching with file-level granularity |
US6874102B2 (en) * | 2001-03-05 | 2005-03-29 | Stratus Technologies Bermuda Ltd. | Coordinated recalibration of high bandwidth memories in a multiprocessor computer |
US6415865B1 (en) | 2001-03-08 | 2002-07-09 | Halliburton Energy Serv Inc | Electron transfer agents in well acidizing compositions and methods |
US7065672B2 (en) * | 2001-03-28 | 2006-06-20 | Stratus Technologies Bermuda Ltd. | Apparatus and methods for fault-tolerant computing using a switching fabric |
US6928583B2 (en) * | 2001-04-11 | 2005-08-09 | Stratus Technologies Bermuda Ltd. | Apparatus and method for two computing elements in a fault-tolerant server to execute instructions in lockstep |
US6957206B2 (en) | 2001-04-19 | 2005-10-18 | Quantum Dynamics, Inc. | Computer system and method with adaptive N-level structures for automated generation of program solutions based on rules input by subject matter experts |
US6996750B2 (en) * | 2001-05-31 | 2006-02-07 | Stratus Technologies Bermuda Ltd. | Methods and apparatus for computer bus error termination |
US7581103B2 (en) * | 2001-06-13 | 2009-08-25 | Intertrust Technologies Corporation | Software self-checking systems and methods |
ES2300454T3 (en) * | 2001-07-26 | 2008-06-16 | Kyocera Wireless Corp. | SYSTEM AND METHOD FOR ORGANIZING A SOFTWARE FOR AN UPDATED WIRELESS COMMUNICATION DEVICE ON THE GROUND. |
US9554268B2 (en) | 2001-07-26 | 2017-01-24 | Kyocera Corporation | System and method for updating persistent data in a wireless communications device |
US7328007B2 (en) | 2001-07-26 | 2008-02-05 | Kyocera Wireless Corp. | System and method for organizing wireless communication device system software |
US7143407B2 (en) | 2001-07-26 | 2006-11-28 | Kyocera Wireless Corp. | System and method for executing wireless communications device dynamic instruction sets |
US7184793B2 (en) | 2001-07-26 | 2007-02-27 | Kyocera Wireless Corp. | System and method for over the air area code update |
US7159214B2 (en) | 2001-07-26 | 2007-01-02 | Kyocera Wireless Corp. | System and method for compacting field upgradeable wireless communication device software code sections |
US7027806B2 (en) | 2001-07-26 | 2006-04-11 | Kyocera Wireless, Corp. | System and method for field downloading a wireless communications device software code section |
US7184759B2 (en) | 2001-07-26 | 2007-02-27 | Kyocera Wireless Corp. | Modular software components for wireless communication devices |
US7386846B2 (en) | 2001-07-26 | 2008-06-10 | Kyocera Wireless Corp. | System and method for the management of wireless communications device system software downloads in the field |
US7254386B2 (en) | 2001-08-10 | 2007-08-07 | Kyocera Wireless Corp. | System and method for improved security in handset reprovisioning and reprogramming |
US6961537B2 (en) | 2001-08-10 | 2005-11-01 | Kyocera Wireless Corp. | System and method for peer-to-peer handset communication |
US8769508B2 (en) | 2001-08-24 | 2014-07-01 | Nazomi Communications Inc. | Virtual machine hardware for RISC and CISC processors |
US6892378B2 (en) * | 2001-09-17 | 2005-05-10 | Hewlett-Packard Development Company, L.P. | Method to detect unbounded growth of linked lists in a running application |
US7191430B2 (en) * | 2001-09-24 | 2007-03-13 | Hewlett-Packard Development Company, L.P. | Providing instruction execution hints to a processor using break instructions |
KR100461535B1 (en) * | 2001-11-02 | 2004-12-14 | 한국전자통신연구원 | Apparatus and Implementation Method of Retargettable Incremental Linking Loarder for Embedded Systems |
US7107582B2 (en) * | 2001-11-15 | 2006-09-12 | International Business Machines Corporation | System and method for source-driven form-independent dynamic content resolution |
US7426719B2 (en) * | 2001-11-29 | 2008-09-16 | Microsoft Corporation | Method and system for rewriting unwind data in the presence of exceptions |
US6653260B2 (en) | 2001-12-07 | 2003-11-25 | Halliburton Energy Services, Inc. | Electron transfer system for well acidizing compositions and methods |
US20030140337A1 (en) * | 2001-12-21 | 2003-07-24 | Celoxica Ltd. | System, method, and article of manufacture for data transfer reporting for an application |
US20030126590A1 (en) * | 2001-12-28 | 2003-07-03 | Michael Burrows | System and method for dynamic data-type checking |
JP2003280754A (en) * | 2002-03-25 | 2003-10-02 | Nec Corp | Hidden source program, source program converting method and device and source converting program |
US7644392B2 (en) * | 2002-04-12 | 2010-01-05 | Telelogic Technologies North America, Inc. | System and method for active configuration management |
US7284246B2 (en) * | 2002-04-23 | 2007-10-16 | Canon Kabushiki Kaisha | Extensible device driver |
CA2383832A1 (en) * | 2002-04-24 | 2003-10-24 | Ibm Canada Limited-Ibm Canada Limitee | System and method for intelligent trap analysis |
US20030217355A1 (en) * | 2002-05-16 | 2003-11-20 | International Business Machines Corporation | System and method of implementing a virtual data modification breakpoint register |
JP3840149B2 (en) * | 2002-06-28 | 2006-11-01 | 株式会社東芝 | Compiler, arithmetic processing system, and arithmetic processing method |
GB0215029D0 (en) * | 2002-06-28 | 2002-08-07 | Critical Blue Ltd | Strand based execution |
US20040019877A1 (en) * | 2002-07-26 | 2004-01-29 | International Business Machines Corporation | System, method and program product for initializing variables in a program |
US20040045018A1 (en) * | 2002-08-27 | 2004-03-04 | Nair Sreekumar R. | Using address space bridge in postoptimizer to route indirect calls at runtime |
US7069279B1 (en) * | 2002-11-04 | 2006-06-27 | Savaje Technologies, Inc. | Timely finalization of system resources |
US7386839B1 (en) | 2002-11-06 | 2008-06-10 | Valery Golender | System and method for troubleshooting software configuration problems using application tracing |
US7484205B2 (en) * | 2002-12-12 | 2009-01-27 | Microsoft Corporation | Preprocessor-based source code instrumentation |
US7603704B2 (en) * | 2002-12-19 | 2009-10-13 | Massachusetts Institute Of Technology | Secure execution of a computer program using a code cache |
US7594111B2 (en) * | 2002-12-19 | 2009-09-22 | Massachusetts Institute Of Technology | Secure execution of a computer program |
US7293263B2 (en) * | 2002-12-20 | 2007-11-06 | Bea Systems, Inc. | System and method for memory leak detection in a virtual machine environment |
US7603661B2 (en) * | 2003-01-30 | 2009-10-13 | Hamilton Sunstrand | Parse table generation method and system |
US7096339B2 (en) * | 2003-03-01 | 2006-08-22 | International Business Machines Corporation | System and method for detecting memory management programming errors |
US8032866B1 (en) | 2003-03-27 | 2011-10-04 | Identify Software Ltd. | System and method for troubleshooting runtime software problems using application learning |
US20040194063A1 (en) * | 2003-03-28 | 2004-09-30 | Joel Pereira | System and method for automated testing of a software module |
US20040255274A1 (en) * | 2003-06-12 | 2004-12-16 | Win-Harn Liu | Test system with flexible extension and maintenance functions and the method thereof |
EP1652033A1 (en) * | 2003-07-08 | 2006-05-03 | Seventh Knight | Automatic regeneration of computer files description |
US7496896B2 (en) * | 2003-07-17 | 2009-02-24 | Computer Associates Think, Inc. | Accessing return values and exceptions |
US7359698B2 (en) | 2003-09-08 | 2008-04-15 | Kyocera Wireless Corp. | Systems and methods for enhanced over-the-air programming |
US7937691B2 (en) * | 2003-09-30 | 2011-05-03 | International Business Machines Corporation | Method and apparatus for counting execution of specific instructions and accesses to specific data locations |
US7395527B2 (en) * | 2003-09-30 | 2008-07-01 | International Business Machines Corporation | Method and apparatus for counting instruction execution and data accesses |
US20050071816A1 (en) * | 2003-09-30 | 2005-03-31 | International Business Machines Corporation | Method and apparatus to autonomically count instruction execution for applications |
US20050071821A1 (en) * | 2003-09-30 | 2005-03-31 | International Business Machines Corporation | Method and apparatus to autonomically select instructions for selective counting |
US20050071612A1 (en) * | 2003-09-30 | 2005-03-31 | International Business Machines Corporation | Method and apparatus for generating interrupts upon execution of marked instructions and upon access to marked memory locations |
US20050071610A1 (en) * | 2003-09-30 | 2005-03-31 | International Business Machines Corporation | Method and apparatus for debug support for individual instructions and memory locations |
US20050071611A1 (en) * | 2003-09-30 | 2005-03-31 | International Business Machines Corporation | Method and apparatus for counting data accesses and instruction executions that exceed a threshold |
US20050071609A1 (en) * | 2003-09-30 | 2005-03-31 | International Business Machines Corporation | Method and apparatus to autonomically take an exception on specified instructions |
US7373637B2 (en) * | 2003-09-30 | 2008-05-13 | International Business Machines Corporation | Method and apparatus for counting instruction and memory location ranges |
US20050071608A1 (en) * | 2003-09-30 | 2005-03-31 | International Business Machines Corporation | Method and apparatus for selectively counting instructions and data accesses |
US7421681B2 (en) * | 2003-10-09 | 2008-09-02 | International Business Machines Corporation | Method and system for autonomic monitoring of semaphore operation in an application |
US7225309B2 (en) * | 2003-10-09 | 2007-05-29 | International Business Machines Corporation | Method and system for autonomic performance improvements in an application via memory relocation |
US8381037B2 (en) | 2003-10-09 | 2013-02-19 | International Business Machines Corporation | Method and system for autonomic execution path selection in an application |
US20050086455A1 (en) * | 2003-10-16 | 2005-04-21 | International Business Machines Corporation | Method and apparatus for generating interrupts for specific types of instructions |
GB2407403A (en) * | 2003-10-22 | 2005-04-27 | Ibm | Validating a variable data item in a software routine |
US7257657B2 (en) * | 2003-11-06 | 2007-08-14 | International Business Machines Corporation | Method and apparatus for counting instruction execution and data accesses for specific types of instructions |
US7458078B2 (en) * | 2003-11-06 | 2008-11-25 | International Business Machines Corporation | Apparatus and method for autonomic hardware assisted thread stack tracking |
US7493599B2 (en) * | 2003-11-26 | 2009-02-17 | Intel Corporation | Device, system and method for detection and handling of misaligned data access |
US7776529B2 (en) | 2003-12-05 | 2010-08-17 | Life Technologies Corporation | Methine-substituted cyanine dye compounds |
US7526757B2 (en) * | 2004-01-14 | 2009-04-28 | International Business Machines Corporation | Method and apparatus for maintaining performance monitoring structures in a page table for use in monitoring performance of a computer program |
US7181599B2 (en) * | 2004-01-14 | 2007-02-20 | International Business Machines Corporation | Method and apparatus for autonomic detection of cache “chase tail” conditions and storage of instructions/data in “chase tail” data structure |
US7197586B2 (en) * | 2004-01-14 | 2007-03-27 | International Business Machines Corporation | Method and system for recording events of an interrupt using pre-interrupt handler and post-interrupt handler |
US7496908B2 (en) * | 2004-01-14 | 2009-02-24 | International Business Machines Corporation | Method and apparatus for optimizing code execution using annotated trace information having performance indicator and counter information |
US7114036B2 (en) * | 2004-01-14 | 2006-09-26 | International Business Machines Corporation | Method and apparatus for autonomically moving cache entries to dedicated storage when false cache line sharing is detected |
US7293164B2 (en) * | 2004-01-14 | 2007-11-06 | International Business Machines Corporation | Autonomic method and apparatus for counting branch instructions to generate branch statistics meant to improve branch predictions |
US7082486B2 (en) * | 2004-01-14 | 2006-07-25 | International Business Machines Corporation | Method and apparatus for counting interrupts by type |
US7392370B2 (en) | 2004-01-14 | 2008-06-24 | International Business Machines Corporation | Method and apparatus for autonomically initiating measurement of secondary metrics based on hardware counter values for primary metrics |
US7093081B2 (en) * | 2004-01-14 | 2006-08-15 | International Business Machines Corporation | Method and apparatus for identifying false cache line sharing |
US7895382B2 (en) * | 2004-01-14 | 2011-02-22 | International Business Machines Corporation | Method and apparatus for qualifying collection of performance monitoring events by types of interrupt when interrupt occurs |
US20050155018A1 (en) * | 2004-01-14 | 2005-07-14 | International Business Machines Corporation | Method and apparatus for generating interrupts based on arithmetic combinations of performance counter values |
US7415705B2 (en) * | 2004-01-14 | 2008-08-19 | International Business Machines Corporation | Autonomic method and apparatus for hardware assist for patching code |
US7290255B2 (en) * | 2004-01-14 | 2007-10-30 | International Business Machines Corporation | Autonomic method and apparatus for local program code reorganization using branch count per instruction hardware |
US20050172275A1 (en) * | 2004-01-29 | 2005-08-04 | Thilo Opatemy | Execution of instructions in an automation system |
US7739689B1 (en) * | 2004-02-27 | 2010-06-15 | Symantec Operating Corporation | Internal monitoring of applications in a distributed management framework |
US20050198624A1 (en) * | 2004-03-02 | 2005-09-08 | Chipman Timothy W. | Method and system for program transformation |
US7987453B2 (en) * | 2004-03-18 | 2011-07-26 | International Business Machines Corporation | Method and apparatus for determining computer program flows autonomically using hardware assisted thread stack tracking and cataloged symbolic data |
US7526616B2 (en) | 2004-03-22 | 2009-04-28 | International Business Machines Corporation | Method and apparatus for prefetching data from a data structure |
US8135915B2 (en) | 2004-03-22 | 2012-03-13 | International Business Machines Corporation | Method and apparatus for hardware assistance for prefetching a pointer to a data structure identified by a prefetch indicator |
US7647358B2 (en) * | 2004-03-22 | 2010-01-12 | Microsoft Corporation | Computing device with relatively limited storage space and operating/file system thereof |
US7299319B2 (en) | 2004-03-22 | 2007-11-20 | International Business Machines Corporation | Method and apparatus for providing hardware assistance for code coverage |
US7421684B2 (en) * | 2004-03-22 | 2008-09-02 | International Business Machines Corporation | Method and apparatus for autonomic test case feedback using hardware assistance for data coverage |
US8069192B2 (en) * | 2004-03-22 | 2011-11-29 | Microsoft Corporation | Computing device with relatively limited storage space and operating / file system thereof |
US7296130B2 (en) | 2004-03-22 | 2007-11-13 | International Business Machines Corporation | Method and apparatus for providing hardware assistance for data access coverage on dynamically allocated data |
US7480899B2 (en) * | 2004-03-22 | 2009-01-20 | International Business Machines Corporation | Method and apparatus for autonomic test case feedback using hardware assistance for code coverage |
US7549150B2 (en) * | 2004-03-24 | 2009-06-16 | Microsoft Corporation | Method and system for detecting potential races in multithreaded programs |
US7496898B1 (en) * | 2004-04-15 | 2009-02-24 | Sun Microsystems, Inc. | Error analysis and diagnosis for generic function calls |
US7930491B1 (en) | 2004-04-19 | 2011-04-19 | Cisco Technology, Inc. | Memory corruption detection system and method using contingency analysis regulation |
US7827539B1 (en) | 2004-06-25 | 2010-11-02 | Identify Software Ltd. | System and method for automated tuning of program execution tracing |
US7457832B2 (en) * | 2004-08-31 | 2008-11-25 | Microsoft Corporation | Verifying dynamically generated operations on a data store |
US7685574B2 (en) * | 2004-09-29 | 2010-03-23 | Microsoft Corporation | Constrained execution regions |
US7457671B2 (en) * | 2004-09-30 | 2008-11-25 | Rockwell Automation Technologies, Inc. | Systems and methods that facilitate management of add-on instruction generation, selection, and/or monitoring during execution |
US8655853B2 (en) * | 2004-10-01 | 2014-02-18 | Sap Ag | System and method for optimizing database transaction termination |
US7624304B2 (en) * | 2004-10-07 | 2009-11-24 | Microsoft Corporation | Defect detection for integers |
US7533373B2 (en) * | 2005-01-25 | 2009-05-12 | Taiwan Semiconductor Manufacturing Co., Ltd | Method for prevention of system execution malfunction |
US8010956B1 (en) * | 2005-01-28 | 2011-08-30 | Oracle America, Inc. | Control transfer table structuring |
US7343523B2 (en) * | 2005-02-14 | 2008-03-11 | Aristoga, Inc. | Web-based analysis of defective computer programs |
US8266608B2 (en) * | 2005-02-18 | 2012-09-11 | Green Hills Software, Inc. | Post-compile instrumentation of object code for generating execution trace data |
US9152531B2 (en) * | 2005-02-18 | 2015-10-06 | Green Hills Sofware, Inc. | Post-compile instrumentation of object code for generating execution trace data |
US7376815B2 (en) * | 2005-02-25 | 2008-05-20 | Qualcomm Incorporated | Methods and apparatus to insure correct predecode |
WO2006104407A1 (en) * | 2005-03-28 | 2006-10-05 | Intel Corporation | A platform independent binary instrumentation method |
US20060222125A1 (en) * | 2005-03-31 | 2006-10-05 | Edwards John W Jr | Systems and methods for maintaining synchronicity during signal transmission |
US20060222126A1 (en) * | 2005-03-31 | 2006-10-05 | Stratus Technologies Bermuda Ltd. | Systems and methods for maintaining synchronicity during signal transmission |
US7735136B2 (en) * | 2005-04-18 | 2010-06-08 | Vmware, Inc. | 0-touch and 1-touch techniques for improving the availability of computer programs under protection without compromising security |
US20060248103A1 (en) * | 2005-04-29 | 2006-11-02 | Cisco Technology, Inc. | Method of detecting memory leaks in software applications |
EP1885718B1 (en) | 2005-05-11 | 2017-03-15 | Life Technologies Corporation | Fluorescent chemical compounds having high selectivity for double stranded dna, and methods for their use |
EP1891520B1 (en) * | 2005-06-07 | 2017-09-13 | VMware, Inc. | Constraint injection system for immunizing software programs against vulnerabilities and attacks |
US20070011499A1 (en) * | 2005-06-07 | 2007-01-11 | Stratus Technologies Bermuda Ltd. | Methods for ensuring safe component removal |
US20060277541A1 (en) * | 2005-06-07 | 2006-12-07 | Sony Computer Entertainment America Inc. | Relocatable component file format |
US7840774B2 (en) * | 2005-09-09 | 2010-11-23 | International Business Machines Corporation | Compressibility checking avoidance |
US7730453B2 (en) * | 2005-12-13 | 2010-06-01 | Microsoft Corporation | Runtime detection for invalid use of zero-length memory allocations |
US20070169062A1 (en) * | 2005-12-20 | 2007-07-19 | Intel Corporation | Suspending memory analyzing of a program performed by a runtime memory analysis system |
US9183114B2 (en) * | 2005-12-27 | 2015-11-10 | International Business Machines Corporation | Error detection on the stack |
US7774761B2 (en) * | 2005-12-27 | 2010-08-10 | International Business Machines Corporation | Use of memory watch points and a debugger to improve analysis of runtime memory access errors |
US7774741B2 (en) * | 2006-05-22 | 2010-08-10 | Microsoft Corporation | Automatically resource leak diagnosis and detecting process within the operating system |
JP4894362B2 (en) * | 2006-06-09 | 2012-03-14 | 富士通株式会社 | Operation status monitoring program |
US20080034349A1 (en) * | 2006-08-04 | 2008-02-07 | Microsoft Corporation | Incremental program modification based on usage data |
US20080098191A1 (en) * | 2006-10-20 | 2008-04-24 | International Business Machines Corporation | Determining code efficiency by monitoring memory reallocation |
US20080120604A1 (en) * | 2006-11-20 | 2008-05-22 | Morris Robert P | Methods, Systems, And Computer Program Products For Providing Program Runtime Data Validation |
US9495278B2 (en) * | 2006-12-27 | 2016-11-15 | International Business Machines Corporation | Dynamic discovery of data segments within instrumented code |
US7730090B2 (en) * | 2007-03-09 | 2010-06-01 | Emc Corporation | Architecture for performing file system checking on an active file system |
US7861231B2 (en) * | 2007-03-09 | 2010-12-28 | International Business Machines Corporation | System and method of identification of dangling pointers |
US20080294853A1 (en) * | 2007-05-25 | 2008-11-27 | Gururaja Kowlali | Method and System for Pinpointing Memory Leaks |
US8930909B1 (en) * | 2007-07-13 | 2015-01-06 | The Mathworks, Inc. | Debugging using presentation layer representations of objects |
GB2451253A (en) * | 2007-07-24 | 2009-01-28 | Ezurio Ltd | Indicating the position of a next declaration statement in object code when declaring a variable object code |
US9483405B2 (en) * | 2007-09-20 | 2016-11-01 | Sony Interactive Entertainment Inc. | Simplified run-time program translation for emulating complex processor pipelines |
US8185880B2 (en) * | 2007-10-04 | 2012-05-22 | International Business Machines Corporation | Optimizing heap memory usage |
US8468500B2 (en) * | 2007-12-12 | 2013-06-18 | Nec Corporation | Program debugging method and program transformation method, program debugging device and program transformation device using the same, and storage medium |
US20090172368A1 (en) * | 2007-12-26 | 2009-07-02 | International Business Machines Corporation | Hardware Based Runtime Error Detection |
US8141055B2 (en) * | 2007-12-31 | 2012-03-20 | International Business Machines Corporation | Method for dynamic discovery of code segments in instrumented binary modules |
US8601443B2 (en) * | 2008-02-12 | 2013-12-03 | International Business Machines Corporation | Method and system for correlating trace data |
US20090228875A1 (en) * | 2008-03-04 | 2009-09-10 | Devries Alex | Method and System for Reducing Disk Allocation by Profiling Symbol Usage |
US8930683B1 (en) | 2008-06-03 | 2015-01-06 | Symantec Operating Corporation | Memory order tester for multi-threaded programs |
US9317399B2 (en) | 2012-09-28 | 2016-04-19 | Synopsys, Inc. | Policy evaluation based upon dynamic observation, static analysis and code change history |
US10713069B2 (en) | 2008-09-04 | 2020-07-14 | Synopsys, Inc. | Software and hardware emulation system |
CN101727355B (en) * | 2008-10-31 | 2013-02-20 | 国际商业机器公司 | Handling method and system for memory access events |
US8001432B2 (en) * | 2008-11-20 | 2011-08-16 | Lsi Corporation | Uninitialized memory detection using error correction codes and built-in self test |
US8438558B1 (en) | 2009-03-27 | 2013-05-07 | Google Inc. | System and method of updating programs and data |
CN101706725B (en) * | 2009-11-20 | 2014-03-19 | 中兴通讯股份有限公司 | Method and system for loading and debugging relocatable program |
US9298427B2 (en) * | 2010-01-06 | 2016-03-29 | Microsoft Technology Licensing, Llc. | Creating inferred symbols from code usage |
JP2011141676A (en) * | 2010-01-06 | 2011-07-21 | Toshiba Corp | Apparatus and method for processing language, and computer program product |
US8572574B2 (en) * | 2010-07-16 | 2013-10-29 | Fujitsu Limited | Solving hybrid constraints to validate specification requirements of a software module |
US8413249B1 (en) | 2010-09-30 | 2013-04-02 | Coverity, Inc. | Threat assessment of software-configured system based upon architecture model and as-built code |
US8799615B2 (en) | 2010-10-21 | 2014-08-05 | International Business Machines Corporation | Organization of a small object area and a large object area in a java heap |
US9342582B2 (en) | 2010-11-22 | 2016-05-17 | Microsoft Technology Licensing, Llc | Selection of atoms for search engine retrieval |
US9424351B2 (en) | 2010-11-22 | 2016-08-23 | Microsoft Technology Licensing, Llc | Hybrid-distribution model for search engine indexes |
US8620907B2 (en) | 2010-11-22 | 2013-12-31 | Microsoft Corporation | Matching funnel for large document index |
US9529908B2 (en) | 2010-11-22 | 2016-12-27 | Microsoft Technology Licensing, Llc | Tiering of posting lists in search engine index |
US9195745B2 (en) | 2010-11-22 | 2015-11-24 | Microsoft Technology Licensing, Llc | Dynamic query master agent for query execution |
US8478704B2 (en) | 2010-11-22 | 2013-07-02 | Microsoft Corporation | Decomposable ranking for efficient precomputing that selects preliminary ranking features comprising static ranking features and dynamic atom-isolated components |
US8713024B2 (en) * | 2010-11-22 | 2014-04-29 | Microsoft Corporation | Efficient forward ranking in a search engine |
US8762952B2 (en) | 2010-12-14 | 2014-06-24 | Bmc Software, Inc. | Recording method calls that led to an unforeseen problem |
US8745598B2 (en) | 2010-12-14 | 2014-06-03 | Bmc Software, Inc. | Running injected code prior to execution of an application |
US20120166982A1 (en) * | 2010-12-27 | 2012-06-28 | Udo Klein | Code list cache for value help |
EP2482191B1 (en) * | 2011-01-31 | 2017-03-22 | Fujitsu Limited | Memory correctness checking in distributed computer systems |
US9116717B2 (en) * | 2011-05-27 | 2015-08-25 | Cylance Inc. | Run-time interception of software methods |
US8898794B1 (en) | 2011-09-06 | 2014-11-25 | Andrei Teodor Borac | Efficient and secure data structure synchronization |
US8843790B2 (en) * | 2012-07-27 | 2014-09-23 | International Business Machines Corporation | Dynamic hardware watchpoint |
US9032376B2 (en) | 2012-09-28 | 2015-05-12 | Synopsys, Inc. | Static analysis of computer code to determine impact of change to a code component upon a dependent code component |
US9612943B2 (en) | 2013-06-28 | 2017-04-04 | Synopsys, Inc. | Prioritization of tests of computer program code |
CN104881611B (en) | 2014-02-28 | 2017-11-24 | 国际商业机器公司 | The method and apparatus for protecting the sensitive data in software product |
US9465768B2 (en) | 2014-03-14 | 2016-10-11 | International Business Machines Corporation | PCI function measurement block enhancements |
WO2016118216A2 (en) | 2014-11-06 | 2016-07-28 | Intertrust Technologies Corporation | Secure application distribution systems and methods |
US9836381B2 (en) | 2015-05-13 | 2017-12-05 | Stensal Inc. | Translating machine codes to store metadata and to propagate metadata for run time checking of programming errors |
US10019244B1 (en) * | 2016-09-28 | 2018-07-10 | Amazon Technologies, Inc. | Interpreting program code using a symbol table |
US10108407B2 (en) * | 2016-10-24 | 2018-10-23 | International Business Machines Corporation | Loading optimized local entry points for local-use-only function pointers |
US10877743B2 (en) * | 2016-11-29 | 2020-12-29 | Mitsubishi Electric Corporation | Control apparatus for updating stored program and method for updating program stored in control apparatus |
US10725894B2 (en) * | 2017-10-04 | 2020-07-28 | International Business Machines Corporation | Measuring and improving test coverage |
DE112018006439T5 (en) * | 2018-03-14 | 2020-09-03 | Mitsubishi Electric Corporation | System design support device, system design support method, and system design support program |
CN109615423B (en) * | 2018-11-29 | 2020-06-16 | 阿里巴巴集团控股有限公司 | Service processing method and device |
US11681806B2 (en) | 2019-10-15 | 2023-06-20 | International Business Machines Corporation | Protecting against out-of-bounds buffer references |
WO2022140336A1 (en) * | 2020-12-21 | 2022-06-30 | RunSafe Security, Inc. | System and methods for live debugging of transformed binaries |
Family Cites Families (45)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4533997A (en) * | 1972-08-25 | 1985-08-06 | Westinghouse Electric Corp. | Computer monitored or controlled system which may be modified and de-bugged on-line by one not skilled in computer programming |
US3815103A (en) * | 1973-01-02 | 1974-06-04 | Honeywell Inf Systems | Memory presence checking apparatus |
US4104718A (en) * | 1974-12-16 | 1978-08-01 | Compagnie Honeywell Bull (Societe Anonyme) | System for protecting shared files in a multiprogrammed computer |
US4394731A (en) * | 1980-11-10 | 1983-07-19 | International Business Machines Corporation | Cache storage line shareability control for a multiprocessor system |
US4589068A (en) | 1983-10-03 | 1986-05-13 | Digital Equipment Corporation | Segmented debugger |
SE441872B (en) * | 1984-04-06 | 1985-11-11 | Ericsson Telefon Ab L M | DEVICE FOR MONITORING A DATA PROCESSING SYSTEM |
US4833604A (en) * | 1986-01-13 | 1989-05-23 | International Business Machines Corporation | Method for the relocation of linked control blocks |
NL8600217A (en) * | 1986-01-30 | 1987-08-17 | Philips Nv | DATA PROCESSING DEVICE CONTAINING A MEMORY DEVICE EQUIPPED WITH A COINCIDENCE CIRCUIT WHICH IS SWITCHABLE IN AN ERROR RECOGNITION AND COINCIDENCE MODE. |
US5115499A (en) * | 1986-05-14 | 1992-05-19 | Sequoia Systems, Inc. | Shared computer resource allocation system having apparatus for informing a requesting computer of the identity and busy/idle status of shared resources by command code |
US4802165A (en) * | 1986-10-08 | 1989-01-31 | Enteleki, Inc. | Method and apparatus of debugging computer programs |
GB2200483B (en) * | 1987-01-22 | 1991-10-16 | Nat Semiconductor Corp | Memory referencing in a high performance microprocessor |
US4964065A (en) | 1987-03-12 | 1990-10-16 | Decibel Products, Inc. | Computer-controlled electronic system monitor |
JP2681929B2 (en) * | 1987-06-22 | 1997-11-26 | 三菱電機株式会社 | Program start method |
US4903194A (en) * | 1987-11-12 | 1990-02-20 | International Business Machines Corporation | Storage addressing error detection circuitry |
US4953084A (en) * | 1987-11-16 | 1990-08-28 | Hewlett-Packard Company | Method and apparatus using variable ranges to support symbolic debugging of optimized code |
US4937736A (en) * | 1987-11-30 | 1990-06-26 | International Business Machines Corporation | Memory controller for protected memory with automatic access granting capability |
US5025366A (en) * | 1988-01-20 | 1991-06-18 | Advanced Micro Devices, Inc. | Organization of an integrated cache unit for flexible usage in cache system design |
US5175837A (en) * | 1989-02-03 | 1992-12-29 | Digital Equipment Corporation | Synchronizing and processing of memory access operations in multiprocessor systems using a directory of lock bits |
US5175828A (en) * | 1989-02-13 | 1992-12-29 | Hewlett-Packard Company | Method and apparatus for dynamically linking subprogram to main program using tabled procedure name comparison |
US5119377A (en) * | 1989-06-16 | 1992-06-02 | International Business Machines Corporation | System and method for software error early detection and data capture |
US5230070A (en) * | 1989-09-08 | 1993-07-20 | International Business Machines Corporation | Access authorization table for multi-processor caches |
US5701427A (en) | 1989-09-19 | 1997-12-23 | Digital Equipment Corp. | Information transfer arrangement for distributed computer system |
US5132972A (en) * | 1989-11-29 | 1992-07-21 | Honeywell Bull Inc. | Assembly language programming potential error detection scheme sensing apparent inconsistency with a previous operation |
US5075842A (en) * | 1989-12-22 | 1991-12-24 | Intel Corporation | Disabling tag bit recognition and allowing privileged operations to occur in an object-oriented memory protection mechanism |
US5404499A (en) * | 1990-01-24 | 1995-04-04 | Logical Services Incorporated | Semi-automatic program execution error detection |
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 |
US5237691A (en) | 1990-08-01 | 1993-08-17 | At&T Bell Laboratories | Method and apparatus for automatically generating parallel programs from user-specified block diagrams |
US5313616A (en) * | 1990-09-18 | 1994-05-17 | 88Open Consortium, Ltd. | Method for analyzing calls of application program by inserting monitoring routines into the executable version and redirecting calls to the monitoring routines |
US5287453A (en) | 1990-09-18 | 1994-02-15 | Bull Hn Information Systems, Inc. | Fast remote file access facility for distributing file access requests in a closely coupled computer system |
EP0496494A3 (en) * | 1991-01-22 | 1993-05-12 | International Business Machines Corporation | Software maintenance system |
CA2035697A1 (en) | 1991-02-05 | 1992-08-06 | Brian James Smyth | Encryption apparatus for computer device |
JP3270102B2 (en) | 1991-03-11 | 2002-04-02 | ヒューレット・パッカード・カンパニー | Licensing method and system |
US5193180A (en) * | 1991-06-21 | 1993-03-09 | Pure Software Inc. | System for modifying relocatable object code files to monitor accesses to dynamically allocated memory |
US5632022A (en) | 1991-11-13 | 1997-05-20 | The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration | Encyclopedia of software components |
US5257381A (en) * | 1992-02-28 | 1993-10-26 | Intel Corporation | Method of intercepting a global function of a network operating system and calling a monitoring function |
US5412788A (en) * | 1992-04-16 | 1995-05-02 | Digital Equipment Corporation | Memory bank management and arbitration in multiprocessor computer system |
US5557780A (en) | 1992-04-30 | 1996-09-17 | Micron Technology, Inc. | Electronic data interchange system for managing non-standard data |
US5388268A (en) | 1992-09-18 | 1995-02-07 | Hewlett-Packard Company | Methods of indicating states of software processes cooperating on a single task |
US5647056A (en) | 1992-11-18 | 1997-07-08 | Canon Information Systems, Inc. | Method and apparatus for managing access to a networked peripheral |
DE69409445D1 (en) | 1993-07-27 | 1998-05-14 | Ibm | Process monitoring in a multiple processing provider |
FR2711026B1 (en) | 1993-10-04 | 1995-12-08 | France Telecom | System for managing the consumption of data consultations on a telecommunications network. |
US5602729A (en) | 1994-03-15 | 1997-02-11 | Mercury Computer Systems, Inc. | Method and apparatus for monitoring and controlling multiprocessor digital data processing systems |
US5528753A (en) * | 1994-06-30 | 1996-06-18 | International Business Machines Corporation | System and method for enabling stripped object software monitoring in a computer system |
WO1996003690A1 (en) | 1994-07-22 | 1996-02-08 | Debenedictis Erik P | Method and apparatus for controlling connected computers without programming |
US5541911A (en) | 1994-10-12 | 1996-07-30 | 3Com Corporation | Remote smart filtering communication management system |
-
1991
- 1991-06-21 US US07/718,573 patent/US5193180A/en not_active Expired - Lifetime
-
1992
- 1992-06-05 DE DE69232761T patent/DE69232761T2/en not_active Expired - Lifetime
- 1992-06-05 CA CA002111958A patent/CA2111958C/en not_active Expired - Fee Related
- 1992-06-05 AU AU21887/92A patent/AU2188792A/en not_active Abandoned
- 1992-06-05 EP EP92913752A patent/EP0591360B1/en not_active Expired - Lifetime
- 1992-06-05 WO PCT/US1992/004672 patent/WO1993000633A1/en active IP Right Grant
- 1992-11-02 US US07/970,315 patent/US5335344A/en not_active Expired - Lifetime
-
1995
- 1995-05-26 US US08/452,452 patent/US5535329A/en not_active Expired - Lifetime
- 1995-05-31 US US08/455,821 patent/US6206584B1/en not_active Expired - Lifetime
-
1996
- 1996-05-31 US US08/658,910 patent/US5835701A/en not_active Expired - Lifetime
-
1999
- 1999-11-04 US US09/434,203 patent/US6618824B1/en not_active Expired - Lifetime
-
2003
- 2003-07-03 US US10/613,516 patent/US7210118B2/en not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
US5535329A (en) | 1996-07-09 |
EP0591360B1 (en) | 2002-09-04 |
DE69232761T2 (en) | 2003-04-24 |
US6206584B1 (en) | 2001-03-27 |
US5335344A (en) | 1994-08-02 |
US5835701A (en) | 1998-11-10 |
CA2111958A1 (en) | 1993-01-07 |
AU2188792A (en) | 1993-01-25 |
US20040107217A1 (en) | 2004-06-03 |
US6618824B1 (en) | 2003-09-09 |
DE69232761D1 (en) | 2002-10-10 |
WO1993000633A1 (en) | 1993-01-07 |
US7210118B2 (en) | 2007-04-24 |
US5193180A (en) | 1993-03-09 |
EP0591360A4 (en) | 1996-04-17 |
EP0591360A1 (en) | 1994-04-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2111958C (en) | Method and apparatus for modifying relocatable object code files and monitoring programs | |
EP0665496B1 (en) | Method and apparatus for run-time error checking using dynamic patching | |
US5675803A (en) | Method and apparatus for a fast debugger fix and continue operation | |
KR100518584B1 (en) | Shared library system and method for constructing the system | |
US5583988A (en) | Method and apparatus for providing runtime checking features in a compiled programming development environment | |
Larus et al. | Rewriting executable files to measure program behavior | |
US6460178B1 (en) | Shared library optimization for heterogeneous programs | |
Ho et al. | An approach to genuine dynamic linking | |
US6067641A (en) | Demand-based generation of symbolic information | |
US5182806A (en) | Incremental compiler for source-code development system | |
US6973646B1 (en) | Method for compiling program components in a mixed static and dynamic environment | |
US20030126590A1 (en) | System and method for dynamic data-type checking | |
US20080052693A1 (en) | Method of simd-ization through data reshaping, padding, and alignment | |
US6810519B1 (en) | Achieving tight binding for dynamically loaded software modules via intermodule copying | |
Agesen et al. | Finding references in Java stacks | |
EP0406028A2 (en) | Incremental compiler for source code development system | |
US20020129336A1 (en) | Automatic symbol table selection in a multi-cell environment | |
Johnson | Postloading for fun and profit | |
Tikir et al. | PMaC binary instrumentation library for PowerPC/AIX | |
Graham et al. | Adaptable Binary Programs. | |
Chen et al. | A source-level instrumentation framework for the dynamic analysis of memory safety | |
CA2426712A1 (en) | Method for signaling errors in memory accesses by a computer program | |
Chen et al. | A dynamic analysis tool for memory safety based on smart status and source-level instrumentation | |
Bishop | Garbage collection in a very large address space | |
JPH08147155A (en) | Method and system for instruction change/insertion of object program |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request | ||
MKLA | Lapsed |