US20020073398A1 - Method and system for modifying executable code to add additional functionality - Google Patents

Method and system for modifying executable code to add additional functionality Download PDF

Info

Publication number
US20020073398A1
US20020073398A1 US09/212,182 US21218298A US2002073398A1 US 20020073398 A1 US20020073398 A1 US 20020073398A1 US 21218298 A US21218298 A US 21218298A US 2002073398 A1 US2002073398 A1 US 2002073398A1
Authority
US
United States
Prior art keywords
instruction
patch
compiled
file
executable
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.)
Abandoned
Application number
US09/212,182
Inventor
Jeffrey L. Tinker
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Apple Inc
NXP USA Inc
Original Assignee
Applied Microsystems Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Applied Microsystems Corp filed Critical Applied Microsystems Corp
Priority to US09/212,182 priority Critical patent/US20020073398A1/en
Assigned to APPLIED MICROSYSTEMS CORPORATION reassignment APPLIED MICROSYSTEMS CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: TINKER, JEFFREY L.
Priority to CA002292123A priority patent/CA2292123C/en
Priority to EP99310012A priority patent/EP1014263A3/en
Priority to JP11355196A priority patent/JP2000181725A/en
Publication of US20020073398A1 publication Critical patent/US20020073398A1/en
Priority to US10/369,225 priority patent/US6948164B2/en
Assigned to METROWERKS CORPORATION reassignment METROWERKS CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: APPLIED MICROSYSTEMS CORPORATION
Assigned to APPLE INC. reassignment APPLE INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ZENITH INVESTMENTS, LLC
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates

Definitions

  • the present invention relates generally to efficiently creating executable software, and more particularly to modifying compiled executable files to add additional functionality.
  • creating executable software code could be a time-consuming task.
  • the typical code creation process involved first creating a source code program (i.e., a series of lines of program statements in a high-level computer language) with a text processing program, compiling and linking the source code (sometimes with an intermediate assembling step) to create executable code (i.e., a series of machine language instructions) for a specified computer processor, and then storing the executable code in an executable file.
  • the executable code could then be debugged by executing the executable file on the specified computer processor to determine if the software performed its task correctly, or if instead it had one or more errors (i.e., bugs).
  • the variables and expressions that were part of the print statements would be evaluated in the context of the current variable scope (e.g., using the value of a local variable in a currently executing function rather than a variable with the same name in a different non-executing function), as would any other compiled code statement.
  • debuggers In addition to print requests, application programs known as debuggers were developed to provide additional control over execution of executable files.
  • a debugger loads executable code into memory and then controls execution of the executable code.
  • the debugger can execute a single executable code instruction at a time. Alternately, the debugger can execute the executable code continuously until a break point designated within the debugger is reached.
  • Such debuggers can also use additional information stored in an executable code file during the compiling and linking steps to reconstruct and display the source code lines that correspond to the instructions in the executable code.
  • the display of the source code facilitates control by the software developer of the execution of the executable code (e.g., setting a breakpoint at a particular point in the source code).
  • debugger When execution of the executable code is stopped, a user can interact with the debugger to view current values of variables and expressions. In addition, some debuggers allow a user to view the effects of temporarily modifying a source code line. Nonetheless, although such debuggers can assist with locating errors in executable compiled code, recompiling and linking is needed to fix errors that are located.
  • Another technique to modify the functionality of compiled code without requiring recompilation and linking involves rewriting an executable file. Rather than modifying an existing file, rewriting involves creating an entirely new executable compiled file based on an existing executable file. Rewriting an executable file does allow new functionality to be added to an executable file at a user-specified location because new compiled instructions can be added to the new file. However, rewriting is difficult to perform without adding errors into the new file, and the specific mechanisms for adding instructions (e.g., adjusting offsets in existing instructions) typically vary on each type of processor.
  • executable code When executable code is being created for an embedded system (e.g., an embedded controller for manufacturing equipment), the problems with software code creation are exacerbated.
  • embedded systems may include only a CPU and memory, without having access to other standard computer system components such as a keyboard or display.
  • standard application programs such as text processors and debuggers may not be available for an embedded system.
  • the source code will typically be created on a host computer system separate from the embedded target system. This allows a user application such as a text processor to create the source code. The source code is then compiled for the target embedded computer system and transferred (e.g, over a network) to the embedded system for execution and debugging.
  • a method and system are provided for modifying a compiled executable code file so as to add functionality when the modified executable code file is executed.
  • the modifying of the executable code file is performed without recompiling, relinking or rewriting the executable code file.
  • the system allows a user to indicate changes to be made to the compiled executable file, including adding code statements to the compiled executable file and manipulating previously added code statements in a variety of ways.
  • Each set of code statements which are to be added is referred to as a patch, with each statement in a patch being referred to as a patch statement.
  • the system modifies the compiled executable code in a non-transitory manner such that the patch statements will be performed when the modified executable code is executed in the future. This manner of modification allows the traditional compile/link/debug cycle to be avoided, thus providing significant time savings.
  • Adding a patch to a compiled executable code file involves creating a patch handler which when executed causes the patch statements to be executed and which may additionally perform various housekeeping functions.
  • the patch statements may be stored in an executable machine-independent non-compiled format, and if so are interpreted when executed on a target computer.
  • Adding a patch may also involve replacing one or more existing compiled instructions in the compiled executable code file with patching instructions which, when executed, will transfer flow of execution to the appropriate patch handler loaded in memory.
  • the existing instructions replaced by the patching instruction can be added to the patch handler so that they will be executed in addition to the patch statements.
  • the patching instructions can directly identify the memory location of a patch handler, such as with a transfer instruction.
  • the patching instructions can include a unique reference to the appropriate patch handler, and if so the appropriate memory location for the referenced patch handler will not be determined until the time of execution.
  • Patches can also include code statements which form a complete module, such as an invokable routine, which can be referenced by other patch statements to cause the module to be executed.
  • patch statements can include variables and expressions that will be evaluated in the context of the appropriate current variable scope, regardless of whether the scope is defined within the patch or by existing compiled instructions.
  • specialized trace requests can also be added to the compiled executable code as patch statements.
  • the trace requests will make specified information about the current execution of the executable code file available to a software developer, such as by storing it on a local trace log file or transmitting it electronically.
  • patches After patches have been added, they can be disabled so as to prevent their execution without removing the patching instructions from the compiled executable file. Patches can also be qualified with conditions such that the patch will be executed only when the conditions are true at the time of execution.
  • the system modifies on a target computer a compiled file executable on the target computer, with the compiled file including a plurality of compiled instructions.
  • the modifying is performed under control of a source computer, and it involves first loading the compiled file onto the target computer and then receiving an indication to modify the compiled file by adding at least one instruction to be executed upon execution of the compiled file.
  • the system then creates a patch group having instructions including the indicated instructions.
  • the system modifies the compiled file on the target computer by replacing an instruction in the compiled file with a patch instruction, and loads the patch group into a portion of memory on the target computer distinct from the memory in which the compiled file is loaded.
  • the system executes on the target computer the instructions in the modified compiled file by, when an instruction to be executed is the patch instruction, indicating one of the plurality of instructions in the loaded patch group as a next instruction to be executed.
  • FIG. 1 is a block diagram illustrating an embodiment of the Code Patcher system of the present invention.
  • FIGS. 2A and 2B illustrate an example of patched software code.
  • FIGS. 3A and 3B illustrate examples of source code in an executable computer-independent non-compiled parse tree format.
  • FIG. 4 is an exemplary flow diagram of an embodiment of the Command Subsystem routine.
  • FIG. 5 is an exemplary flow diagram of an embodiment of the Process Patch Request subroutine.
  • FIG. 6 is an exemplary flow diagram of an embodiment of the Patching Subsystem routine.
  • FIG. 7 is an exemplary flow diagram of an embodiment of the Code Fragment Executables System routine.
  • FIG. 8 is an exemplary flow diagram of an embodiment of the Patch Interpreter Subsystem routine.
  • FIG. 9 is an exemplary flow diagram of an embodiment of the Execute Patched Executable Code subroutine.
  • An embodiment of the present invention provides a method and system for modifying a compiled executable code file so as to add functionality when the modified executable code file is executed.
  • the modifying of the executable code file is performed without recompiling, relinking or rewriting the executable code file.
  • the Code Patcher system loads compiled executable code into memory on a target computer, and allows a user to indicate patches to be made to the compiled executable file.
  • patches can include adding code statements (i e., compiled instructions or lines of source code) to the compiled executable file.
  • the source code lines corresponding to the compiled executable instructions in the file can be shown, and the user can indicate the changes to be made in the displayed source code.
  • the Code Patcher system modifies the compiled executable code in a non-transitory manner such that the patches will be performed when the modified executable code is executed in the future. This manner of modification allows the traditional compile/link/debug cycle to be avoided, thus providing significant time savings.
  • FIG. 1 illustrates an embodiment of a Code Patcher system 133 in which the patching of a compiled executable code file occurs on a host computer system 100 that is separate from a target computer system 150 on which the patched executable code is to be executed.
  • Compiled executable code files to be patched contain compiled instructions which are executable as native code on the CPU of target computer system 150 , and which may or may not be executable as native code on the CPU of host computer system 100 .
  • the target computer system 150 has a RISC processor in which all instructions are the same length, so one compiled instruction will require the same memory space as another compiled instruction.
  • code statements are converted into a machine-independent non-compiled format that will be executed interpretively on the target computer system 150 .
  • code statements could alternatively be compiled and that the Code Patcher system 133 is not limited to patching code for RISC processors.
  • the host computer system 100 includes a CPU 110 , input/output devices 120 , a memory 130 , and a bus 105 .
  • the input/output devices include a storage device 126 , a network connection 122 , a display 124 , and a keyboard 125 .
  • the Code Patcher system 133 is executing in memory 130 , and can be used to patch compiled executable code files such as compiled executable code file 132 stored on the storage device 126 .
  • the Code Patcher system 133 can also be stored on a storage device (not shown) such as storage device 126 before being loaded into memory 130 , and the compiled executable code file 132 may also be loaded into memory 130 to assist operation of the Code Patcher system (e.g., for display to a user).
  • the target computer system 150 similarly includes a CPU 160 , input/output devices 170 , the memory 180 , and a bus 155 .
  • the input/output devices 170 include a storage device 171 and a network connection 172 .
  • a Patch Interpreter Subsystem 181 is executing in memory 180 to assist in the execution of one or more patched executable code files on target computer system 150 .
  • the executable code file 132 is loaded into memory 180 when it is to be executed. After the executable code file is patched and becomes patched executable code file 182 , the patch handlers 184 and code fragment executables 186 that are associated with the patched executable code file are also loaded into memory 180 .
  • the memory 180 also includes some or all of a Link Translation Table 188 in which current memory locations associated with various identifiers are stored, and of a Trace Log 189 in which information will be stored by the Patch Interpreter Subsystem 181 for later retrieval.
  • Link Translation Table 188 and Trace Log 189 could be stored on storage device 171 and be accessed by Patch Interpreter Subsystem 181 only when needed.
  • the Patch Interpreter Subsystem 181 , patched executable code file 182 , patch handlers 184 , and code fragment executables 186 can also be stored on a storage device (not shown) such as storage device 171 before being loaded into memory 180 .
  • the Command Subsystem 134 provides a user interface to a user (not shown) of the host computer system 100 .
  • the Command Subsystem 134 allows the user to specify a compiled executable code file that is to be patched, such as code file 132 .
  • the Command Subsystem 134 then loads information from executable code file 132 (e.g., from the symbol table) to allow a correspondence to be established between the compiled executable code instructions in the file and the original source code lines (not shown) from which the compiled executable code was created.
  • the Command Subsystem 134 displays the source code to the user and allows the user to specify a variety of commands.
  • a user can use the Command Subsystem 134 to modify the file by specifying patches.
  • Each set of code statements which are to be added is referred to as a patch, with each added code statement in a patch referred to as a patch statement.
  • Executable code which has been patched is similarly referred to as patched code.
  • adding a patch to a compiled executable code file involves first creating an executable patch handler which causes the patch statements to be executed (and which may additionally perform various housekeeping functions) and then replacing one or more existing compiled instructions in the file with a patching instruction to transfer flow of execution to the patch handler.
  • patch statements are stored in an executable machine-independent non-compiled format, and are interpreted (i.e., interpretively evaluated) by an evaluator when executed on target computer system 150 .
  • Patch Interpreter Subsystem 181 acts as an evaluator in the illustrated embodiment. Evaluators can be efficiently provided to a variety of target computer systems by cross-compiling an existing evaluator for each of the target systems.
  • patch statements are stored as the original lines of source code and a source code interpreter (not shown) on target computer system 150 is used to interpret the patch statements.
  • patch statements are compiled for target computer system 150 before execution and are then executed natively on the target computer system.
  • a specified patch can take a variety of forms, such as substituting one or more new code statements for one or more existing compiled instructions or lines of source code. After they are substituted for, existing compiled instructions will no longer be executed. Rather than substituting new code statements, a specified patch can also be added such that it is executed in addition to the existing compiled instructions, including even the instructions replaced by patching instructions. This is accomplished by adding the replaced instructions to the patch handler for the patch. Multiple lines or instructions can be included in a patch, even when substituting for a single instruction or when no instructions are being substituted for. Some patches include code statements which form a complete module, such as an invokable routine.
  • patches include one or more code statements which do not form a complete module, referred to as a code fragment. Such patches will typically require that a patching instruction be added so that flow of execution reaches the code fragment. However, if a patch handler including a code fragment is referenced by another patch handler, the code fragment may not directly require a patching instruction for it to be executed.
  • patch statements can include variables and expressions that will be evaluated in the context of the appropriate current variable scope, regardless of whether the scope is defined within the patch or by existing compiled instructions. Access to various information for the compiled executable code file to be patched, such as the symbol table, may be needed to resolve references to variables.
  • trace requests can also be added to a compiled executable code file as patch statements.
  • target computer systems such as embedded systems without a display
  • the trace requests will store specified information about the current execution of the executable code file in a manner that is accessible to a software developer. For example, if the executable code file is being executed on an embedded computer system, the trace mechanism can store execution information in a trace log file on the embedded computer system for later retrieval, or can transmit the information to a separate computer system for access there.
  • the specified information for a trace request can also include variables and expressions that will be evaluated in the context of the current variable scope at the time of their execution.
  • the trace requests can be used to track each time that a particular instruction or block of code is executed. For example, the first instruction in an invokable procedure can be patched with a trace request indicating the current values of the procedure parameters.
  • a patch When a patch is to be added to compiled executable code file 132 , the user indicates the patch statements for the patch as well as where the patch is to be added (e.g., in a particular function or at a specific source code or compiled instruction location).
  • a patching instruction need replace only a single existing instruction since all RISC instructions are the same size.
  • the user also specifies whether the patch is to substitute for existing compiled instructions or is to be added in addition to the existing instructions.
  • it is determined or specified whether the patch is to be added before or after the existing instructions.
  • the patch is added at the first instruction for the function (i.e., the patching instruction replaces the first instruction for the function).
  • the Command Subsystem 134 identifies the one or more corresponding compiled instructions. If multiple instructions correspond to a source code line, one or more of the compiled instructions are selected to be replaced by the patching instruction. The determination of whether the patch is to be added before or after the existing instructions may affect which of the multiple corresponding instructions are selected (e.g., if the patch is added before the instructions, selecting the first of the multiple corresponding instructions).
  • the Command Subsystem 134 also allows the user to perform actions on existing patches, such as to group patches together and to manipulate them either individually or as a group. For example, a patch previously added to the compiled executable code file can be disabled so as to prevent its execution. Patches can also be qualified with conditions such that the patch will be executed only when the conditions are true at the time of execution. In addition, different patches can be grouped together and each group can be manipulated in the same manner as a single patch. For example, all patches in a group can be enabled or disabled, or can be saved for later use. This ability to group, disable/enable, and qualify patches without recompiling the file allows trace requests to be turned on or off in a simple and efficient manner, greatly simplifying debugging. Finally, a user can also use the Command Subsystem 134 to retrieve and view previously created trace information, such as from a trace log.
  • the Command Subsystem 134 notifies a Patching Subsystem 136 of the patches and notifies a Code Fragment Executables Subsystem 138 of the code statements from the patches.
  • the Code Fragment Executables Subsystem 138 converts each sequence of one or more code statements it receives into a code fragment executable 186 in an executable machine-independent non-compiled format. Code fragment executables can be executed in an interpreted manner on any target system with an evaluator for the format.
  • the code fragment executables are stored as parse trees, as is illustrated further with respect to FIGS. 3A and 3B.
  • Each code fragment executable will be associated with the corresponding code file being patched, and will also have a unique identifier by which it can be referenced. For example, other statements can use the unique identifier for a code fragment executable representing a module to invoke the module.
  • Link Translation Table 188 includes a reference for each symbol in each of the code fragment executables 186 which can be referenced by statements outside the code fragment executable (e.g., the unique identifier for a code fragment executable and any exported symbols that can be referenced outside the code fragment executable).
  • Link Translation Table 188 could be stored in an alternate location such as on the host computer system 100 .
  • the code fragment executables 186 could initially be stored on storage device 126 before being transferred, and could be transferred directly to memory 180 or first to storage device 171 .
  • the Patching Subsystem 136 When the Patching Subsystem 136 receives notification of the patches from the Command Subsystem 134 , the Patching Subsystem 136 creates the appropriate patch handlers 184 and places patching instructions in the appropriate locations in the compiled executable file 182 . In addition, in some embodiments, the Patching Subsystem 136 can allocate and deallocate computer system resources on the target computer system 150 needed for the patch handlers 184 (e.g., memory in which to load the patch handlers). The Patching Subsystem 136 first transfers the compiled executable code file 132 to the target computer system 150 .
  • the Patching Subsystem 136 transfers the patch handlers 184 to the target computer system 150 , and updates Link Translation Table 188 as necessary to include references for the patch handlers 184 .
  • the Patching Subsystem 136 also modifies the compiled executable code file on the target computer to include the patching instructions, thus creating patched compiled executable code file 182 .
  • the patch handlers 184 could initially be stored on storage device 126 before being transferred, and could be transferred directly to memory 180 or first to storage device 171 .
  • the Patching Subsystem 136 replaces an existing compiled instruction with a patching instruction, thus removing the replaced instruction from patched compiled executable file 182 .
  • an already-patched code file such as file 182 could have additional patches added.
  • an old patching instruction could be selected as the instruction to be replaced with a new patching instruction. If the new patch is intended to supplement rather than substitute for the previous patch, the replaced old patching instruction can be added to the new patch handler so that the old patch handler will be also executed.
  • Each patching instruction alters the flow of execution to an appropriate patch handler so that the patch statements for the patch will be executed.
  • each patch has a distinct patch handler, while in an alternate embodiment a single patch handler can handle all patches.
  • the patching instructions are transfer statements (e.g., jump, goto, branch, call, etc.) which specify an explicit memory location (either directly or via an offset) in which the patch handler will be executed.
  • the patching instructions include a unique reference to the appropriate patch handler, and the appropriate memory location for the referenced patch handler is determined from Link Translation Table 188 at the time of execution.
  • the patching instructions are trap instructions, and the appropriate memory location for the referenced patch handler is determined from a return Program Counter map.
  • the patching of compiled executable file 132 is performed without recompiling, relinking or rewriting the file.
  • Patching Subsystem 136 In addition to inserting patching instructions, Patching Subsystem 136 must also create appropriate patch handlers 184 so that the patch statements are exhibited when flow of execution is transferred to the patch handler. Each patch handler 184 will first save the current state of execution (e.g., register and stack values) if necessary, and then include the code fragment executables and/or trace requests to be executed for the patch. If the patch is to be added to compiled executable code 132 rather than substituting for the compiled instruction replaced by the patching instruction, the replaced instruction must also be added to the patch handler so that it will be executed. For example, if the patch is to be added after the replaced instruction, then the replaced instruction would be added at the beginning of the patch handler before any of the patch statements.
  • Each patch handler 184 will first save the current state of execution (e.g., register and stack values) if necessary, and then include the code fragment executables and/or trace requests to be executed for the patch. If the patch is to be added to compiled executable code
  • the patch handler will, if necessary, restore the saved state of the computer and will then return the flow of execution to the instruction in the compiled executable code after the patching instruction.
  • each patch handler 184 will be uniquely identified in some way so that it can be referenced by its associated patching instruction.
  • a patch handler will always be loaded at a specific location in memory 180 on target computer system 150 , and thus the patching instruction can explicitly indicate that memory location when the patching instruction is added to the patched compiled executable file 182 by the Patching Subsystem 136 .
  • This memory 180 location can be identified at the time the patch handler 184 is created if the Patching Subsystem 136 performs memory management for the target computer system 150 in which it can allocate and deallocate blocks of memory.
  • the Patching Subsystem 136 could request that the target computer system 150 allocate a block of memory 180 and provide the memory location information to the Patching Subsystem 136 .
  • patch handlers 184 are loaded into different locations of memory 180 with each execution of the patched executable code file 182 .
  • Link Translation Table 188 can be used to map a unique identifier for each patch handler 184 to its current location in memory 180 .
  • code fragment executables 186 can be stored with patch handlers 184 and loaded into the memory block for the patch handlers, or can instead be loaded into separate locations in memory 180 .
  • a patch handler can merely reference a unique identifier for a code fragment executable, and Link Translation Table 188 can be used to identify the current memory location at which to access the code fragment executable.
  • patch handlers 184 and code fragment executables 186 are loaded into different locations of memory 180 with each execution of the patched executable code file 182 , but rather than using Link Translation Table 188 the patched compiled executable file 182 is modified before each execution so that identifiers are replaced with the current memory location for the associated item.
  • the Patch Interpreter Subsystem 181 on the target computer system 150 controls the execution.
  • the Patch Interpreter Subsystem 181 ensures that compiled instructions are executed as compiled native code on target computer system 150 , while patch statements (if stored in machine-independent form) are interpreted.
  • the Patch Interpreter Subsystem 181 also uses Link Translation Table 188 to resolve references to symbols, modules, code fragment executables, and patch handlers as necessary. Thus, if a patching instruction merely references the unique identifier for a patch handler 184 , the Patch Interpreter Subsystem 181 will identify the memory location of the patch handler and transfer flow of execution there rather than trying to execute the patching instruction as native code.
  • the specified information for the trace request is stored in an appropriate manner, such as in Trace Log 189 .
  • the Patch Interpreter Subsystem 181 performs its interpreted evaluation in a manner so as to ensure that variables and expressions are evaluated in the context of the appropriate current variable scope. In one mode, the Patch Interpreter Subsystem 181 works independently without external influence. In an alternate mode, a user on the host computer system 100 can use the Command Subsystem 134 to interact with Patch Interpreter Subsystem 181 and to control execution of the patched executable file 182 .
  • the target computer system 150 is an embedded computer system
  • the Code Patcher system 133 is part of a debugger on the distinct host computer system 100
  • the compiled executable file 132 is a terminal emulator to be executed on the embedded system.
  • the Code Patcher system 133 allows a user to perform normal debugging functions (e.g., single stepping through a compiled program) but also allows the user to interactively modify an existing compiled executable code file in a permanent manner without requiring a compile/link/transfer/debug cycle.
  • the user can also manipulate the patches in a variety of ways in this embodiment. For example, a patch can be added to the compiled executable code file but can be disabled.
  • the functionality added by the patch is not executed while the patch is disabled, either by replacing the patch with the original patched instruction or by indicating to the Patch Interpreter Subsystem 181 to not execute the patch statements.
  • different patches can be grouped together and each group can be manipulated in the same manner as a single patch. For example, all patches in a group can be enabled or disabled, or can be saved for later use. Patches can also be qualified with conditions such that the patch will be executed only when the conditions are true at the time of execution.
  • the Code Patcher system 133 can be used for a variety of other purposes.
  • an executable code file may have been incomplete when compiled.
  • references to symbols e.g., variables or functions
  • the Code Patcher system 133 can be used to replace the stubs with references to code fragment executables.
  • additional functionality can be added even to compiled executable code files that lack errors. For example, a graphical user interface could be added to an executable code file with only a command-line interpreter, or new functionality can be added to handle inputs or situations not anticipated at the original time of compilation.
  • FIGS. 2A and 2B illustrates sequences of compiled instructions from a compiled executable code file. For readability, a corresponding source code line is shown for each instruction. Those skilled in the art will appreciate that the particular source code lines are merely illustrative.
  • FIG. 2B illustrates the same compiled executable code file after various patches have been added. In particular, five patches, including a code fragment executable module, have been added to the original compiled executable code file.
  • Patch 1 demonstrates a patch that adds a trace request before instruction N.
  • instruction N is replaced in the compiled executable code file with a patching instruction that indicates to transfer flow of execution to a patch handler for Patch 1 .
  • the patch handler first saves the current state of the target system on which execution is occurring. The patch handler then issues a trace request for a designated string of information. The original patched instruction, instruction N, is then executed in the patch handler.
  • Patch 1 executes the trace request in addition to, rather than substituted for, the replaced instruction N. After executing instruction N, the original state of the computer system is then restored before the flow of execution is returned to instruction N+1.
  • an execution such as the trace request can be performed in a variety of ways, such as by writing the specified information to a file or by sending the information to another computer, such as in a message object or as text in an email message. Alternately, trace information can be output using any other communication means (e.g., pager, cellular phone, display device, etc.). Note that although the trace request in Patch 1 did not include any variables or expressions to be evaluated, instruction N will require the evaluation of the variables a and c. This evaluation will occur in the context of the appropriate current variable scope.
  • Patch 2 reflects a patch which replaces instruction N+3 with multiple patch statements, including both a trace request and a code fragment executable. Patch 2 also demonstrates a patch that substitutes for an existing instruction rather than adding patch statements, and thus existing instruction N+3 will be not executed in the patched executable code file.
  • the patch handler When flow of execution is transferred to the patch handler for Patch 2 , the patch handler first saves the current target computer system state. The patch handler then executes the trace request and the code fragment executable as shown. Note that this trace request will require the evaluation of variable a, which will be performed in the context of the appropriate current variable scope. The code fragment executable will be executed in an interpreted manner. After executing the various instructions in the patch handler, the original computer system state is restored before returning flow of execution to instruction N+4.
  • the code fragment executable module labeled FN 2 has also been added as part of the patch process.
  • Patch 3 adds patch statements before instruction N+6, including a call to the newly created module.
  • Patch 3 also illustrates that multiple code statements can be executed within a patch handler (limited only by available memory on the target computer system).
  • the appropriate computer system state is first saved.
  • the next patch statement calls module FN 2 with the variable b as a parameter.
  • each of the patch handlers can return flow of execution to the compiled instructions in a variety of ways, such as using a return statement or explicitly using the memory location of the next compiled instruction.
  • each code statement has a separate code fragment executable, while in another embodiment the various code statements in a patch handler are combined into a single code fragment executable.
  • Patch 4 illustrates that compiled functions can be patched and traced in a manner similar to that of any other compiled instruction. For example, if a user desires to trace all invocations of the function FN 1 , Patch 4 can be added before the first instruction of the function, instruction P.
  • the trace requests in Patch 4 illustrate that when the variable X is evaluated, it will be evaluated using the current variable scope of function FN 1 , but that the global variable Y will be evaluated using the appropriate variable scope for Y, which may be the entire program rather than the local scope of function FN 1 .
  • Those skilled in the art will appreciate that a variety of other patches are possible.
  • FIGS. 3A and 3B illustrative examples of code fragment executables stored in an executable machine-independent non-compiled format are shown.
  • the exemplary machine-independent format shown are parse trees.
  • the original source code line can be reconstructed by using depth-first search along the parse tree, using non-leaf nodes only after the first child branch has been used.
  • FIG. 3B illustrates a possible parse tree for the source code function Swap as shown.
  • parse tree As the parse tree is read from left to right and upwards from the leaf nodes, the appropriate order of statements for the Swap function is retrieved.
  • a parse tree can be represented using different formats, and that parse trees are only one possible format for encoding executable machine-independent code fragment executables.
  • FIG. 4 is an exemplary flow diagram of an embodiment of the Command Subsystem routine 400 .
  • the Command Subsystem routine will receive a command from a user to either patch a compiled executable code file such as code file 132 or to execute an already patched executable code file such as patched code file 182 .
  • patches can be added to a compiled executable code file that already contains patches (and can even patch already patched instructions), as well as to a compiled executable code file without patches.
  • the routine will accept a variety of trace requests and code fragments to be added to the code file, will combine multiple patches if they are to be added at the same compiled instruction in the compiled executable code file, and will notify the Patching Subsystem 136 (FIG. 1) and the Code Fragment Executables Subsystem 138 (FIG. 1) of the patches.
  • the routine can receive commands, relay them to the Patch Interpreter Subsystem 181 (FIG. 1), and receive and display to the user the results of the execution of the command.
  • the Command Subsystem 134 provides interactive control over a patched executable code file, a user can determine whether or not to view the source code for patches (e.g., not viewing source code for disabled patches).
  • the Command Subsystem routine begins at step 405 where a command is received from a user.
  • the routine continues in step 410 to determine if the command is to patch a compiled executable code file. If so, the routine continues to step 415 where it receives an indication of the executable code file to be patched.
  • the routine then continues in step 420 to load information from the symbol table of the indicated executable code file, thus allowing the source code lines corresponding to the compiled executable code instructions to be displayed to the user.
  • the routine then continues to step 425 where a request is received from the user that is related to patching the compiled executable code file.
  • the routine continues in step 430 to execute the Process Patch Request subroutine to process the request. As is explained in greater detail with relation to FIG.
  • possible patch requests include adding various trace requests or code fragments, grouping and degrouping patches, and manipulating previously created patches.
  • the routine continues in step 435 to determine if there are more patch requests from the user. If so, the routine returns to step 425 to receive the next patch request.
  • step 440 to sequence patches together when they will replace the same compiled instruction. Since any given compiled instruction in the compiled executable code file can only be replaced with a single patching instruction to a patch handler, multiple patches that have been associated with a single compiled instruction must be sequenced together. Additional steps may also need to be taken to ensure that all patches are executed and that the correct order of patch execution is followed. In the illustrated embodiment, multiple patches associated with a single compiled instruction are placed in a single patch handler for the patching instruction that will replace the compiled instruction.
  • multiple patch handlers could be used, with each patch handler transferring flow of execution to the next patch handler in sequence and with the last patch handler returning the flow of execution to the compiled instruction following the patching instruction.
  • a sequence in which to execute the multiple patches must be selected. For example, all trace requests could be executed either before or after all code fragments.
  • the user indicates the sequence of patches when the patches are created.
  • step 440 the routine continues to step 445 to notify the Patching Subsystem 136 of the patch sequences to be added to the compiled executable code file, including sequences of a single patch.
  • step 450 to notify the Code Fragment Executables Subsystem 138 of the code fragments, including created modules, that have been added as patches to the compiled executable code file.
  • step 455 determine if there are more commands from the user. If so, the routine returns to step 405 to receive a user command, and if not, the routine ends at step 499 .
  • step 410 If it is instead determined in step 410 that the received user command is not to patch a compiled executable code file, the routine continues to step 460 where an indication of a patched compiled executable code file is received.
  • This patched code file will be executed on an indicated target computer system.
  • the patched code and any associated patch handlers and code fragment executables will have been transferred to the indicated target system when the patching occurred. Alternately, the transferring could occur after step 460 .
  • the routine next continues to step 465 to determine if the patched code file is to be executed with interactive control by the user.
  • step 470 the Patch Interpreter Subsystem 181 is notified to execute the patched executable code file without waiting for interactive commands. If instead it is determined in step 465 that the patched executable code file is to be executed interactively, the routine continues instead to step 475 where the Patch Interpreter Subsystem 181 is notified to execute the patched executable code file in an interactive execution mode.
  • step 480 receives an execution-related command from the user.
  • Such commands could include setting or removing break points, checking the current values of variables and expressions, or stepping through the execution a single line at a time. In the illustrated embodiments, the manipulation of patches does not occur during interactive execution, but such functionality could be provided in an alternate embodiment.
  • step 485 the routine notifies the Patch Interpreter Subsystem 181 of the command, and in step 490 the results of the command execution are received from the Patch Interpreter Subsystem 181 and are displayed to the user.
  • step 495 to determine if there are more interactive execution commands from the user. If so, the routine returns to step 480 to receive the next user command.
  • step 470 the routine continues to step 455 to determine if there are more user commands.
  • the Command Subsystem routine can be implemented in a variety of ways. For example, other top-level user commands than patching compiled executable code files and executing patched compiled executable code files could be processed by the routine. Alternately, separate routines could be used to patch a compiled executable code file and to execute a patched compiled executable code file.
  • FIG. 5 is an exemplary flow diagram of an embodiment of the Process Patch Request subroutine 430 .
  • the Process Patch Request subroutine receives a user request related to patching the compiled executable code file, determines the type of patch request, and satisfies the patch request.
  • the user indicates source code lines corresponding to compiled instructions in the compiled executable code file for patch requests, and the Code Patcher system 133 selects the appropriate compiled instruction for the indicated source code line when performing the request.
  • the subroutine begins at step 505 where it is determined if the patch request is to add a trace request to indicate when a source code line is executed. If so, the subroutine continues to step 510 to add the trace request to an appropriate patch handler, which will be referenced by a patching instruction that replaces a compiled instruction corresponding to the indicated source code line. If it is instead determined that the trace request is not to trace a source code line, the subroutine continues to step 515 to determine if the patch request is to add a trace request to indicate when a function in the compiled executable code file is executed. If so, the subroutine continues to step 520 to add a trace request to a patch handler for the first instruction of the indicated function.
  • the subroutine continues to step 525 to determine if the patch request is to add a trace request for a specified expression at a particular source line. If so, the subroutine continues to step 530 to add a trace request for the expression to a patch handler at the indicated source line. If the patch request is not to trace a specified expression, the subroutine instead continues to step 535 to determine if the patch request is to add a specified code fragment to the compiled executable code file. If so, the subroutine continues to step 540 to add the specified code fragment executable to a patch handler at the compiled instruction corresponding to an indicated source line. The user can also indicate whether the patch is to substitute for the instruction or to be added in addition to the instruction, and when the patch is added in addition to the instruction whether the patch is to be executed before or after the source code line.
  • step 545 determines if the patch request is to create a code fragment module. If so, the subroutine continues to step 550 where an invokable code module with multiple source code statements is specified by the user, and an associated code fragment executable module is created for the patched executable code file. If it is determined in step 545 that the patch request is not to create a code module, then the subroutine continues to step 555 to determine if the patch request is to group patches together or to degroup previously grouped patches into individual patches.
  • step 560 the subroutine continues to step 560 to perform the indicated grouping or degrouping. If the patch request is not to group or degroup patches, the subroutine continues to step 565 to determine if the patch request is to manipulate a patch or patch group. If so, the subroutine continues in step 570 to manipulate the patch or the patches in a patch group as indicated. After step 510 , 520 , 530 , 540 , 550 , 560 , or 570 , or if it is determined in step 565 that the patch request does not manipulate a patch or a patch group, the subroutine continues to step 590 where it returns.
  • FIG. 6 is an exemplary flow diagram of an embodiment of the Patching Subsystem routine 600 .
  • the Patching Subsystem routine is notified by the Command Subsystem routine when patch sequences are to be added or manipulated for a compiled executable code file.
  • the Patching Subsystem routine then creates the necessary patch handlers, patches the compiled executable code file in the appropriate manner, and loads the patch handlers and the patched compiled executable code file onto a target system.
  • the routine begins at step 605 where one or more patch sequences are received for a compiled executable code file.
  • This notification from the Command Subsystem 134 can also indicate that previously added patches have been manipulated (e.g., removed or disabled).
  • step 610 The routine continues in step 610 to select the next received patch sequence to be added or manipulated, beginning with the first received patch sequence.
  • the routine then continues to step 615 , where an appropriate patch handler is created if the selected patch sequence indicates that a patching instruction is to be added to the compiled executable code file.
  • an existing patch handler can be accordingly modified or a new patch handler can be created to replace an existing patch handler. For example, if a previously added patch is being removed, the original patched instruction can be reinserted in the compiled executable code file in place of the patching instruction.
  • the first instruction of the patch handler could be modified to cause a jump to the end of the patch handler or to the instruction following the patching instruction.
  • the patch handler for that patch can be modified to include evaluation statements to determine if the specified conditions are true.
  • step 615 the routine continues to 620 to, if a patching instruction needs to be added, replace the appropriate compiled executable code instruction with a patching instruction (e.g., a jump statement) to the created patched handler.
  • a patching instruction e.g., a jump statement
  • an existing patch handler is merely being modified, it will not be necessary to replace a compiled instruction with a patching instruction since the existing patching instruction will still be effective.
  • a patch handler can be invoked in a variety of ways, such as by using an interrupt mechanism or by including an identifier that will be resolved at execution time to indicate an appropriate location in memory on the target system.
  • step 620 the routine continues in step 625 to determine if there are more patch sequences to be selected. If so, the routine returns to step 610 to select the next patch sequence, and if not, the routine continues to step 630 .
  • the routine in step 630 loads the patched executable code file onto the target system.
  • the routine then continues in step 635 to load any created and/or modified patch handlers onto the target system.
  • the Patching Subsystem 136 does not perform memory management for target computer system 150 , so the memory locations on the target system in which the created patch handlers will be loaded will not be known until execution time.
  • the patching instructions inserted into the compiled executable code file merely reference the appropriate patch handler, with the reference to the appropriate memory location to be resolved at execution time. This type of reference resolution allows linking to be delayed until execution time.
  • step 635 the routine continues in step 640 to update a Link Translation Table on the target system to reflect the unique identifiers for the created patch handlers.
  • step 640 the routine continues to step 645 to determine if there are more patch sequences to receive. If so, the routine returns to step 605 to receive patch sequences, and if not the routine continues to step 690 and ends.
  • FIG. 7 is an exemplary flow diagram of an embodiment of the Code Fragment Executables Subsystem routine 700 .
  • the Code Fragment Executables Subsystem routine receives notifications from the Command Subsystem 134 when code fragments are to be added to the compiled executable code file, creates machine-independent non-compiled code fragment executables that can be interpreted by the Patch Interpreter Subsystem 181 , and loads the created code fragment executables onto the target system.
  • the routine begins in step 705 where code fragments to be added to the compiled executable code file are received from the Command Subsystem.
  • the routine continues to step 710 to select the next code fragment, beginning with the first code fragment.
  • step 715 the routine then creates a code fragment executable for the selected code fragment in a machine-independent format not specific to the target computer.
  • the code fragment executables are stored in parse tree format.
  • step 720 the routine then continues in step 720 to determine if there are more code fragments to process. If so, the routine returns to step 710 to select the next code fragment, and if not the routine continues to step 725 .
  • the routine in step 725 loads the created code fragment executables onto the target system.
  • the routine then continues to step 730 to update the Link Translation Table on the target system to reflect the references for the created code fragment executables. For example, if invokable code modules have been created for the patched compiled executable code file, an entry in the Link Translation Table can be used to resolve at execution time a reference to a code module, allowing flow of execution to be transferred to the appropriate memory location where the code fragment executable for the module is loaded in memory.
  • the Link Translation Table can be used to resolve references to those variables by other portions of the code.
  • the code fragment executables are loaded into memory separate from the patch handlers that will reference those code fragment executables, then the Link Translation Table can be used to resolve the references for each such code fragment executable.
  • step 730 the routine continues in step 735 to determine if there are more code fragments to receive. If so, the routine returns to step 705 , and if not the routine ends at step 790 .
  • FIG. 8 is an exemplary flow diagram of an embodiment of the Patch Interpreter Subsystem routine 800 .
  • the Patch Interpreter Subsystem routine receives an indication of a patched executable code file to be executed, loads the patched compiled executable code file as well as associated patch handlers and code fragment executables into memory, executes the non-patched compiled instructions as native code for the target system, and executes the patch statements in an interpreted manner.
  • the Patch Interpreter Subsystem 181 or another subsystem could compile the target-independent code fragment executables into compiled instructions that are native to the particular target system. In this situation, the Patch Interpreter Subsystem 181 would only be needed to resolve references, such as for patch handlers and code fragment executable modules, when such references are included in the patched compiled executable code file.
  • the routine begins in step 805 where an indication is received of the patched executable code file to be executed. In the illustrated embodiment, this indication is received from the Command Subsystem 134 on the host computer system. In an alternate embodiment, the Patch Interpreter Subsystem 181 could receive instructions directly from a user on the target computer system if the target system included the necessary input/output devices.
  • the routine then continues to step 810 to load the patch handlers and code fragment executables associated with the patched compiled executable code file into memory if they are not already stored in memory.
  • the routine then continues to step 815 to ensure that the Link Translation Table reflects the current memory addresses for the code fragment executables and the patch handlers.
  • step 815 the routine continues to step 820 where the patched compiled executable code file is loaded into memory if it is not already stored in memory.
  • the routine then continues to step 825 to execute the Execute Patched Executable Code subroutine.
  • the routine then continues to step 830 to determine if there are more patched compiled executable code files to execute. If so, the routine returns to step 805 , and if not, the routine ends at step 890 .
  • the Patch Interpreter Subsystem routine could execute multiple different patched executable code files at the same time.
  • FIG. 9 is an exemplary flow diagram of an embodiment of the Execute Patched Executable Code subroutine 825 .
  • the Execute Patched Executable Code subroutine receives and executes user commands if an interactive execution of the patched compiled executable code file is in process. When a non-patched compiled instruction is to be executed, it is executed as native code. For each patch statement, the subroutine first determines if the statement is to be executed and then resolves link identifiers if necessary. The subroutine then satisfies trace requests by writing the specified trace information to a trace log on the target system, executes code fragment executables by interpreting them, and notifies the Code Patcher system 133 of the execution status after the instruction has been processed.
  • the subroutine begins at step 905 where it is determined if the current execution of the patched compiled executable code file is to be done in an interactive mode. If so, the routine continues in step 910 to receive a user command. The subroutine then continues to step 915 to determine if the received command is to execute the current instruction in the patched executable code file. If not, the subroutine continues to step 920 to execute the user command, and then continues to step 925 to notify the Code Patcher system 133 of the results of executing the command. For example, a user may wish to see a current value for a variable or to specify a break point at a spot in the patched compiled executable code file.
  • the user may indicate to continue execution in a non-interactive mode until a break point is reached, thus causing execution to stop and returning execution of the patched executable code file to an interactive mode.
  • the subroutine returns to step 905 .
  • step 905 If it was instead determined in step 905 that the execution of the patched executable code file is not currently in interactive mode, or if it was determined in step 915 that the user command was to execute the current instruction, the subroutine continues in step 930 to select the next instruction in the patched executable code file, beginning with the first instruction. The subroutine then continues to step 931 to determine whether the current instruction is to be currently executed.
  • the current instruction could be a patching instruction for a patch that is disabled or that is qualified with a condition that is not currently met in the current environment.
  • step 970 the Code Patcher system 133 will be notified of the status of execution of the current instruction if execution is occurring in an interactive mode.
  • the status of the patch handler can be indicated in a variety of ways. For example, a flag could be set when the patch handler was entered indicating that patch statements are not to be currently executed while the flag is set, with the flag being reset when the end of the patch handler is reached. Alternately, the patch handler could cause the flow of execution to skip any disabled patch statements.
  • step 931 If it is determined in step 931 that the current instruction is to be executed, the subroutine continues to step 932 to determine if the instruction is a compiled instruction. If so, the subroutine continues to step 933 to execute the current instruction in native mode on the target system, and then continues to step 970 . If it is instead determined in step 932 that the current instruction is a non-compiled patch statement or patching instruction, the subroutine continues in step 935 to determine if the current instruction includes a link identifier reference that needs to be resolved. If so, the subroutine continues in step 940 to use the Link Translation Table to resolve the link identifier so that the current position in memory for the associated code can be accessed.
  • step 940 the subroutine continues in step 945 to determine if the current instruction is a trace request. If so, the subroutine continues to step 950 to write the specified trace information to a trace log on the target system that can be retrieved by a user on the host computer system 100 . If the trace request includes variable or expressions to be evaluated, they will be evaluated in the context of the current variable scope.
  • step 945 the subroutine continues to step 965 to execute the code fragment executable by interpreting it within the context of the current variable scope.
  • a global variable X may be defined, with the current flow of execution first entering Function 1 with a variable X that is local to that function and then entering a Function 2 with a distinct local variable X for that function. If patch code within Function 2 requires the evaluation of variable X, its current variable binding within the scope of Function 2 will be used for the evaluation.
  • the current variable scope can be determined in a variety of ways, such as by using symbol table information from the patched executable code file or the current variable block on the stack.
  • step 950 or 965 the subroutine continues at step 970 to notify the Code Patcher system 133 of the status of executing the current instruction if execution is occurring in interactive mode.
  • the subroutine then continues to step 975 to determine if there are more instructions to be executed in the patched compiled executable code file. If so, the subroutine returns to step 905 , and if not the subroutine returns in step 990 .

Abstract

A system for modifying a compiled executable code file by adding patches that add functionality when the modified executable code file is executed. The modifying is performed without recompiling, relinking or rewriting the code file. Adding a patch involves creating a patch handler which when executed causes the patch statements to be executed, and may involve replacing one or more existing compiled instructions in the file with patching instructions to transfer flow of execution to the appropriate patch handler. The instructions replaced by the patching instructions can also be added to the patch handler. Patches can also include code statements which form a complete module, such as an invokable routine, which can be referenced by other patch statements to cause the module to be executed. Specialized trace requests can also be added as patch statements. The trace requests will make specified information about the current execution of the executable code file available to a software developer. Patch statements can include variables and expressions that will be evaluated in the context of the appropriate current variable scope, regardless of whether the scope is defined within the patch or by existing compiled instructions. After patches have been added, they can be disabled so as to prevent their execution without removing the patching instructions from the compiled executable file. Patches can also be qualified with conditions such that the patch will be executed only when the conditions are true at the time of execution.

Description

    TECHNICAL FIELD
  • The present invention relates generally to efficiently creating executable software, and more particularly to modifying compiled executable files to add additional functionality. [0001]
  • BACKGROUND OF THE INVENTION
  • In the past, creating executable software code could be a time-consuming task. The typical code creation process involved first creating a source code program (i.e., a series of lines of program statements in a high-level computer language) with a text processing program, compiling and linking the source code (sometimes with an intermediate assembling step) to create executable code (i.e., a series of machine language instructions) for a specified computer processor, and then storing the executable code in an executable file. The executable code could then be debugged by executing the executable file on the specified computer processor to determine if the software performed its task correctly, or if instead it had one or more errors (i.e., bugs). If the executable code had errors, a software developer would modify the source code in an attempt to remove the errors, recompile the source code, and then link the recompiled code to produce a new executable file for debugging. For large software programs, this process was iteratively performed a large number of times until all known errors were removed. [0002]
  • In many cases, the cause of an error (e.g., a mistake in the program logic) is not obvious from executing the executable file. Various options existed for a software developer to identify errors. For example, a software developer could add print statements throughout the source code so that as the corresponding executable print instructions are executed (after compiling and linking), they would report the current progress of the execution. Knowledge of the current execution progress assists in identifying the section of the code which was executing when an error occurred. In addition to merely reporting execution progress, print statements can also display the current value of variables or source code expressions at specified points throughout the execution. Since the print statements were part of the original compilation/linking process, the variables and expressions that were part of the print statements would be evaluated in the context of the current variable scope (e.g., using the value of a local variable in a currently executing function rather than a variable with the same name in a different non-executing function), as would any other compiled code statement. [0003]
  • In addition to print requests, application programs known as debuggers were developed to provide additional control over execution of executable files. A debugger loads executable code into memory and then controls execution of the executable code. For example, the debugger can execute a single executable code instruction at a time. Alternately, the debugger can execute the executable code continuously until a break point designated within the debugger is reached. Such debuggers can also use additional information stored in an executable code file during the compiling and linking steps to reconstruct and display the source code lines that correspond to the instructions in the executable code. The display of the source code facilitates control by the software developer of the execution of the executable code (e.g., setting a breakpoint at a particular point in the source code). When execution of the executable code is stopped, a user can interact with the debugger to view current values of variables and expressions. In addition, some debuggers allow a user to view the effects of temporarily modifying a source code line. Nonetheless, although such debuggers can assist with locating errors in executable compiled code, recompiling and linking is needed to fix errors that are located. [0004]
  • In addition to the use of debuggers, other techniques have been developed to modify the functionality of compiled code without requiring a full recompilation and linking. One technique involves relinking previously compiled code with different code than was previously used for linking (e.g, using an updated Dynamic-Link Library or replacing a stubbed routine with a functional routine). In this situation, no changes are made to the previously compiled code, but changes in the overall program functionality can occur due to the different operation of the newly linked code. However, this technique is not typically useful in modifying errors in the compiled code (since the compiled code is not changed) or in flexibly adding functionality to an executable file at a desired user-specified location (since only previously specified link points can be used for the relinking). [0005]
  • Another technique to modify the functionality of compiled code without requiring recompilation and linking involves rewriting an executable file. Rather than modifying an existing file, rewriting involves creating an entirely new executable compiled file based on an existing executable file. Rewriting an executable file does allow new functionality to be added to an executable file at a user-specified location because new compiled instructions can be added to the new file. However, rewriting is difficult to perform without adding errors into the new file, and the specific mechanisms for adding instructions (e.g., adjusting offsets in existing instructions) typically vary on each type of processor. [0006]
  • When executable code is being created for an embedded system (e.g., an embedded controller for manufacturing equipment), the problems with software code creation are exacerbated. Such embedded systems may include only a CPU and memory, without having access to other standard computer system components such as a keyboard or display. In addition, standard application programs such as text processors and debuggers may not be available for an embedded system. In this environment, the source code will typically be created on a host computer system separate from the embedded target system. This allows a user application such as a text processor to create the source code. The source code is then compiled for the target embedded computer system and transferred (e.g, over a network) to the embedded system for execution and debugging. When an error occurs during execution of the executable code on the embedded system, the lack of standard computer system components and application programs on the target system make it extremely difficult to determine the cause of the error. Even obtaining information about the current state of the execution at the time of the error is typically difficult. Moreover, even if such information is available, it will need to be transferred back to the host computer system where modifications to the source code can begin another compile/link/transfer/debug cycle. [0007]
  • SUMMARY OF THE INVENTION
  • In accordance with one aspect of the present invention, a method and system are provided for modifying a compiled executable code file so as to add functionality when the modified executable code file is executed. The modifying of the executable code file is performed without recompiling, relinking or rewriting the executable code file. In particular, the system allows a user to indicate changes to be made to the compiled executable file, including adding code statements to the compiled executable file and manipulating previously added code statements in a variety of ways. Each set of code statements which are to be added is referred to as a patch, with each statement in a patch being referred to as a patch statement. After the patches have been specified, the system modifies the compiled executable code in a non-transitory manner such that the patch statements will be performed when the modified executable code is executed in the future. This manner of modification allows the traditional compile/link/debug cycle to be avoided, thus providing significant time savings. [0008]
  • Adding a patch to a compiled executable code file involves creating a patch handler which when executed causes the patch statements to be executed and which may additionally perform various housekeeping functions. The patch statements may be stored in an executable machine-independent non-compiled format, and if so are interpreted when executed on a target computer. Adding a patch may also involve replacing one or more existing compiled instructions in the compiled executable code file with patching instructions which, when executed, will transfer flow of execution to the appropriate patch handler loaded in memory. When a patch is intended to be executed in addition to the existing compiled instructions (rather than substituting for one or more instructions), the existing instructions replaced by the patching instruction can be added to the patch handler so that they will be executed in addition to the patch statements. The patching instructions can directly identify the memory location of a patch handler, such as with a transfer instruction. Alternately, the patching instructions can include a unique reference to the appropriate patch handler, and if so the appropriate memory location for the referenced patch handler will not be determined until the time of execution. Patches can also include code statements which form a complete module, such as an invokable routine, which can be referenced by other patch statements to cause the module to be executed. In addition, patch statements can include variables and expressions that will be evaluated in the context of the appropriate current variable scope, regardless of whether the scope is defined within the patch or by existing compiled instructions. Finally, specialized trace requests can also be added to the compiled executable code as patch statements. The trace requests will make specified information about the current execution of the executable code file available to a software developer, such as by storing it on a local trace log file or transmitting it electronically. After patches have been added, they can be disabled so as to prevent their execution without removing the patching instructions from the compiled executable file. Patches can also be qualified with conditions such that the patch will be executed only when the conditions are true at the time of execution. [0009]
  • In accordance with one aspect of the present invention, the system modifies on a target computer a compiled file executable on the target computer, with the compiled file including a plurality of compiled instructions. The modifying is performed under control of a source computer, and it involves first loading the compiled file onto the target computer and then receiving an indication to modify the compiled file by adding at least one instruction to be executed upon execution of the compiled file. The system then creates a patch group having instructions including the indicated instructions. The system then modifies the compiled file on the target computer by replacing an instruction in the compiled file with a patch instruction, and loads the patch group into a portion of memory on the target computer distinct from the memory in which the compiled file is loaded. The system then executes on the target computer the instructions in the modified compiled file by, when an instruction to be executed is the patch instruction, indicating one of the plurality of instructions in the loaded patch group as a next instruction to be executed.[0010]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a block diagram illustrating an embodiment of the Code Patcher system of the present invention. [0011]
  • FIGS. 2A and 2B illustrate an example of patched software code. [0012]
  • FIGS. 3A and 3B illustrate examples of source code in an executable computer-independent non-compiled parse tree format. [0013]
  • FIG. 4 is an exemplary flow diagram of an embodiment of the Command Subsystem routine. [0014]
  • FIG. 5 is an exemplary flow diagram of an embodiment of the Process Patch Request subroutine. [0015]
  • FIG. 6 is an exemplary flow diagram of an embodiment of the Patching Subsystem routine. [0016]
  • FIG. 7 is an exemplary flow diagram of an embodiment of the Code Fragment Executables System routine. [0017]
  • FIG. 8 is an exemplary flow diagram of an embodiment of the Patch Interpreter Subsystem routine. [0018]
  • FIG. 9 is an exemplary flow diagram of an embodiment of the Execute Patched Executable Code subroutine. [0019]
  • DETAILED DESCRIPTION OF THE INVENTION
  • An embodiment of the present invention provides a method and system for modifying a compiled executable code file so as to add functionality when the modified executable code file is executed. The modifying of the executable code file is performed without recompiling, relinking or rewriting the executable code file. In particular, the Code Patcher system loads compiled executable code into memory on a target computer, and allows a user to indicate patches to be made to the compiled executable file. These patches can include adding code statements (i e., compiled instructions or lines of source code) to the compiled executable file. In one embodiment, the source code lines corresponding to the compiled executable instructions in the file can be shown, and the user can indicate the changes to be made in the displayed source code. After the patches have been indicated, the Code Patcher system modifies the compiled executable code in a non-transitory manner such that the patches will be performed when the modified executable code is executed in the future. This manner of modification allows the traditional compile/link/debug cycle to be avoided, thus providing significant time savings. [0020]
  • FIG. 1 illustrates an embodiment of a [0021] Code Patcher system 133 in which the patching of a compiled executable code file occurs on a host computer system 100 that is separate from a target computer system 150 on which the patched executable code is to be executed. Compiled executable code files to be patched contain compiled instructions which are executable as native code on the CPU of target computer system 150, and which may or may not be executable as native code on the CPU of host computer system 100. In addition, in the illustrated embodiment the target computer system 150 has a RISC processor in which all instructions are the same length, so one compiled instruction will require the same memory space as another compiled instruction. Moreover, code statements are converted into a machine-independent non-compiled format that will be executed interpretively on the target computer system 150. Those skilled in the art will appreciate that code statements could alternatively be compiled and that the Code Patcher system 133 is not limited to patching code for RISC processors.
  • The [0022] host computer system 100 includes a CPU 110, input/output devices 120, a memory 130, and a bus 105. The input/output devices include a storage device 126, a network connection 122, a display 124, and a keyboard 125. The Code Patcher system 133 is executing in memory 130, and can be used to patch compiled executable code files such as compiled executable code file 132 stored on the storage device 126. The Code Patcher system 133 can also be stored on a storage device (not shown) such as storage device 126 before being loaded into memory 130, and the compiled executable code file 132 may also be loaded into memory 130 to assist operation of the Code Patcher system (e.g., for display to a user).
  • The [0023] target computer system 150 similarly includes a CPU 160, input/output devices 170, the memory 180, and a bus 155. The input/output devices 170 include a storage device 171 and a network connection 172. A Patch Interpreter Subsystem 181 is executing in memory 180 to assist in the execution of one or more patched executable code files on target computer system 150. The executable code file 132 is loaded into memory 180 when it is to be executed. After the executable code file is patched and becomes patched executable code file 182, the patch handlers 184 and code fragment executables 186 that are associated with the patched executable code file are also loaded into memory 180. The memory 180 also includes some or all of a Link Translation Table 188 in which current memory locations associated with various identifiers are stored, and of a Trace Log 189 in which information will be stored by the Patch Interpreter Subsystem 181 for later retrieval. In an alternate embodiment, Link Translation Table 188 and Trace Log 189 could be stored on storage device 171 and be accessed by Patch Interpreter Subsystem 181 only when needed. The Patch Interpreter Subsystem 181, patched executable code file 182, patch handlers 184, and code fragment executables 186 can also be stored on a storage device (not shown) such as storage device 171 before being loaded into memory 180.
  • When the [0024] Code Patcher system 133 is first invoked, the Command Subsystem 134 provides a user interface to a user (not shown) of the host computer system 100. The Command Subsystem 134 allows the user to specify a compiled executable code file that is to be patched, such as code file 132. The Command Subsystem 134 then loads information from executable code file 132 (e.g., from the symbol table) to allow a correspondence to be established between the compiled executable code instructions in the file and the original source code lines (not shown) from which the compiled executable code was created. The Command Subsystem 134 then displays the source code to the user and allows the user to specify a variety of commands.
  • After specifying compiled [0025] executable file 132, a user can use the Command Subsystem 134 to modify the file by specifying patches. Each set of code statements which are to be added is referred to as a patch, with each added code statement in a patch referred to as a patch statement. Executable code which has been patched (i.e., modified by having a patch added) is similarly referred to as patched code. As is explained in greater detail below, adding a patch to a compiled executable code file involves first creating an executable patch handler which causes the patch statements to be executed (and which may additionally perform various housekeeping functions) and then replacing one or more existing compiled instructions in the file with a patching instruction to transfer flow of execution to the patch handler.
  • In the illustrated embodiment, patch statements are stored in an executable machine-independent non-compiled format, and are interpreted (i.e., interpretively evaluated) by an evaluator when executed on [0026] target computer system 150. Patch Interpreter Subsystem 181 acts as an evaluator in the illustrated embodiment. Evaluators can be efficiently provided to a variety of target computer systems by cross-compiling an existing evaluator for each of the target systems. In an alternate embodiment, patch statements are stored as the original lines of source code and a source code interpreter (not shown) on target computer system 150 is used to interpret the patch statements. In yet another embodiment, patch statements are compiled for target computer system 150 before execution and are then executed natively on the target computer system.
  • A specified patch can take a variety of forms, such as substituting one or more new code statements for one or more existing compiled instructions or lines of source code. After they are substituted for, existing compiled instructions will no longer be executed. Rather than substituting new code statements, a specified patch can also be added such that it is executed in addition to the existing compiled instructions, including even the instructions replaced by patching instructions. This is accomplished by adding the replaced instructions to the patch handler for the patch. Multiple lines or instructions can be included in a patch, even when substituting for a single instruction or when no instructions are being substituted for. Some patches include code statements which form a complete module, such as an invokable routine. If such a module is being added so that it can be invoked by other code statements, rather than to be directly executed at a designated location, it is not necessary to use patching instructions to execute the module. Instead, other patch statements can reference the module and thus transfer flow of execution to the module. [0027]
  • Other patches include one or more code statements which do not form a complete module, referred to as a code fragment. Such patches will typically require that a patching instruction be added so that flow of execution reaches the code fragment. However, if a patch handler including a code fragment is referenced by another patch handler, the code fragment may not directly require a patching instruction for it to be executed. In addition, patch statements can include variables and expressions that will be evaluated in the context of the appropriate current variable scope, regardless of whether the scope is defined within the patch or by existing compiled instructions. Access to various information for the compiled executable code file to be patched, such as the symbol table, may be needed to resolve references to variables. [0028]
  • In addition to adding code statements, specialized trace requests can also be added to a compiled executable code file as patch statements. For some target computer systems, such as embedded systems without a display, it can be difficult to gather information about execution of executable code since traditional output mechanisms (e.g., print statements) are unavailable or are difficult to use. The trace requests will store specified information about the current execution of the executable code file in a manner that is accessible to a software developer. For example, if the executable code file is being executed on an embedded computer system, the trace mechanism can store execution information in a trace log file on the embedded computer system for later retrieval, or can transmit the information to a separate computer system for access there. The specified information for a trace request can also include variables and expressions that will be evaluated in the context of the current variable scope at the time of their execution. In addition to reporting the current values of variables and expressions, the trace requests can be used to track each time that a particular instruction or block of code is executed. For example, the first instruction in an invokable procedure can be patched with a trace request indicating the current values of the procedure parameters. [0029]
  • When a patch is to be added to compiled [0030] executable code file 132, the user indicates the patch statements for the patch as well as where the patch is to be added (e.g., in a particular function or at a specific source code or compiled instruction location). In the illustrated embodiment, a patching instruction need replace only a single existing instruction since all RISC instructions are the same size. The user also specifies whether the patch is to substitute for existing compiled instructions or is to be added in addition to the existing instructions. In addition, when a patch is being added in addition to existing instructions, it is determined or specified whether the patch is to be added before or after the existing instructions. When a function is indicated as the patch location, the patch is added at the first instruction for the function (i.e., the patching instruction replaces the first instruction for the function). When a source code line is indicated, the Command Subsystem 134 identifies the one or more corresponding compiled instructions. If multiple instructions correspond to a source code line, one or more of the compiled instructions are selected to be replaced by the patching instruction. The determination of whether the patch is to be added before or after the existing instructions may affect which of the multiple corresponding instructions are selected (e.g., if the patch is added before the instructions, selecting the first of the multiple corresponding instructions).
  • The [0031] Command Subsystem 134 also allows the user to perform actions on existing patches, such as to group patches together and to manipulate them either individually or as a group. For example, a patch previously added to the compiled executable code file can be disabled so as to prevent its execution. Patches can also be qualified with conditions such that the patch will be executed only when the conditions are true at the time of execution. In addition, different patches can be grouped together and each group can be manipulated in the same manner as a single patch. For example, all patches in a group can be enabled or disabled, or can be saved for later use. This ability to group, disable/enable, and qualify patches without recompiling the file allows trace requests to be turned on or off in a simple and efficient manner, greatly simplifying debugging. Finally, a user can also use the Command Subsystem 134 to retrieve and view previously created trace information, such as from a trace log.
  • After all the patches have been specified and the user is ready to execute the [0032] code file 132 as patched, the Command Subsystem 134 notifies a Patching Subsystem 136 of the patches and notifies a Code Fragment Executables Subsystem 138 of the code statements from the patches. The Code Fragment Executables Subsystem 138 converts each sequence of one or more code statements it receives into a code fragment executable 186 in an executable machine-independent non-compiled format. Code fragment executables can be executed in an interpreted manner on any target system with an evaluator for the format. In one embodiment, the code fragment executables are stored as parse trees, as is illustrated further with respect to FIGS. 3A and 3B. Each code fragment executable will be associated with the corresponding code file being patched, and will also have a unique identifier by which it can be referenced. For example, other statements can use the unique identifier for a code fragment executable representing a module to invoke the module.
  • After creating the code fragment executables [0033] 186 for the code statements in the patches, the Code Fragment Executables Subsystem 138 then transfers the created code fragment executables to target computer system 150 and updates Link Translation Table 188. Link Translation Table 188 includes a reference for each symbol in each of the code fragment executables 186 which can be referenced by statements outside the code fragment executable (e.g., the unique identifier for a code fragment executable and any exported symbols that can be referenced outside the code fragment executable). Those skilled in the art will appreciate that in an alternate embodiment, Link Translation Table 188 could be stored in an alternate location such as on the host computer system 100. In addition, those skilled in the art will appreciate that the code fragment executables 186 could initially be stored on storage device 126 before being transferred, and could be transferred directly to memory 180 or first to storage device 171.
  • When the [0034] Patching Subsystem 136 receives notification of the patches from the Command Subsystem 134, the Patching Subsystem 136 creates the appropriate patch handlers 184 and places patching instructions in the appropriate locations in the compiled executable file 182. In addition, in some embodiments, the Patching Subsystem 136 can allocate and deallocate computer system resources on the target computer system 150 needed for the patch handlers 184 (e.g., memory in which to load the patch handlers). The Patching Subsystem 136 first transfers the compiled executable code file 132 to the target computer system 150. After creating the patch handlers 184, the Patching Subsystem 136 transfers the patch handlers 184 to the target computer system 150, and updates Link Translation Table 188 as necessary to include references for the patch handlers 184. The Patching Subsystem 136 also modifies the compiled executable code file on the target computer to include the patching instructions, thus creating patched compiled executable code file 182. Those skilled in the art will appreciate that the patch handlers 184 could initially be stored on storage device 126 before being transferred, and could be transferred directly to memory 180 or first to storage device 171.
  • In particular, at each location in the [0035] executable code file 132 where a patch is to be added, the Patching Subsystem 136 replaces an existing compiled instruction with a patching instruction, thus removing the replaced instruction from patched compiled executable file 182. Those skilled in the art will appreciate that in an alternate embodiment, an already-patched code file such as file 182 could have additional patches added. In that embodiment, an old patching instruction could be selected as the instruction to be replaced with a new patching instruction. If the new patch is intended to supplement rather than substitute for the previous patch, the replaced old patching instruction can be added to the new patch handler so that the old patch handler will be also executed. Each patching instruction alters the flow of execution to an appropriate patch handler so that the patch statements for the patch will be executed.
  • In one embodiment, each patch has a distinct patch handler, while in an alternate embodiment a single patch handler can handle all patches. Thus, when the flow of execution reaches a patching instruction, execution will be transferred to and will continue at the appropriate patch handler. In some embodiments, the patching instructions are transfer statements (e.g., jump, goto, branch, call, etc.) which specify an explicit memory location (either directly or via an offset) in which the patch handler will be executed. In alternate embodiments, the patching instructions include a unique reference to the appropriate patch handler, and the appropriate memory location for the referenced patch handler is determined from Link Translation Table [0036] 188 at the time of execution. In yet other embodiments, the patching instructions are trap instructions, and the appropriate memory location for the referenced patch handler is determined from a return Program Counter map. Thus, in these embodiments the patching of compiled executable file 132 is performed without recompiling, relinking or rewriting the file.
  • In addition to inserting patching instructions, [0037] Patching Subsystem 136 must also create appropriate patch handlers 184 so that the patch statements are exhibited when flow of execution is transferred to the patch handler. Each patch handler 184 will first save the current state of execution (e.g., register and stack values) if necessary, and then include the code fragment executables and/or trace requests to be executed for the patch. If the patch is to be added to compiled executable code 132 rather than substituting for the compiled instruction replaced by the patching instruction, the replaced instruction must also be added to the patch handler so that it will be executed. For example, if the patch is to be added after the replaced instruction, then the replaced instruction would be added at the beginning of the patch handler before any of the patch statements. Alternately, if the patch is to be added before the replaced instruction, the replaced instruction would instead be added after the patch statements. Finally, the patch handler will, if necessary, restore the saved state of the computer and will then return the flow of execution to the instruction in the compiled executable code after the patching instruction.
  • Similarly to the created code fragment executables [0038] 186, each patch handler 184 will be uniquely identified in some way so that it can be referenced by its associated patching instruction. In one embodiment, a patch handler will always be loaded at a specific location in memory 180 on target computer system 150, and thus the patching instruction can explicitly indicate that memory location when the patching instruction is added to the patched compiled executable file 182 by the Patching Subsystem 136. This memory 180 location can be identified at the time the patch handler 184 is created if the Patching Subsystem 136 performs memory management for the target computer system 150 in which it can allocate and deallocate blocks of memory. Alternately, the Patching Subsystem 136 could request that the target computer system 150 allocate a block of memory 180 and provide the memory location information to the Patching Subsystem 136. In an alternate embodiment, patch handlers 184 are loaded into different locations of memory 180 with each execution of the patched executable code file 182. In that embodiment, Link Translation Table 188 can be used to map a unique identifier for each patch handler 184 to its current location in memory 180. In a similar manner, code fragment executables 186 can be stored with patch handlers 184 and loaded into the memory block for the patch handlers, or can instead be loaded into separate locations in memory 180. If loaded separately in memory 180, a patch handler can merely reference a unique identifier for a code fragment executable, and Link Translation Table 188 can be used to identify the current memory location at which to access the code fragment executable. In another embodiment, patch handlers 184 and code fragment executables 186 are loaded into different locations of memory 180 with each execution of the patched executable code file 182, but rather than using Link Translation Table 188 the patched compiled executable file 182 is modified before each execution so that identifiers are replaced with the current memory location for the associated item.
  • When the patched [0039] executable code file 182 is to be executed, the Patch Interpreter Subsystem 181 on the target computer system 150 controls the execution. In particular, the Patch Interpreter Subsystem 181 ensures that compiled instructions are executed as compiled native code on target computer system 150, while patch statements (if stored in machine-independent form) are interpreted. The Patch Interpreter Subsystem 181 also uses Link Translation Table 188 to resolve references to symbols, modules, code fragment executables, and patch handlers as necessary. Thus, if a patching instruction merely references the unique identifier for a patch handler 184, the Patch Interpreter Subsystem 181 will identify the memory location of the patch handler and transfer flow of execution there rather than trying to execute the patching instruction as native code. As trace requests are encountered during execution, the specified information for the trace request is stored in an appropriate manner, such as in Trace Log 189. The Patch Interpreter Subsystem 181 performs its interpreted evaluation in a manner so as to ensure that variables and expressions are evaluated in the context of the appropriate current variable scope. In one mode, the Patch Interpreter Subsystem 181 works independently without external influence. In an alternate mode, a user on the host computer system 100 can use the Command Subsystem 134 to interact with Patch Interpreter Subsystem 181 and to control execution of the patched executable file 182.
  • In one embodiment, the [0040] target computer system 150 is an embedded computer system, the Code Patcher system 133 is part of a debugger on the distinct host computer system 100, and the compiled executable file 132 is a terminal emulator to be executed on the embedded system. In this embodiment, the Code Patcher system 133 allows a user to perform normal debugging functions (e.g., single stepping through a compiled program) but also allows the user to interactively modify an existing compiled executable code file in a permanent manner without requiring a compile/link/transfer/debug cycle. The user can also manipulate the patches in a variety of ways in this embodiment. For example, a patch can be added to the compiled executable code file but can be disabled. In this situation, the functionality added by the patch is not executed while the patch is disabled, either by replacing the patch with the original patched instruction or by indicating to the Patch Interpreter Subsystem 181 to not execute the patch statements. In addition, different patches can be grouped together and each group can be manipulated in the same manner as a single patch. For example, all patches in a group can be enabled or disabled, or can be saved for later use. Patches can also be qualified with conditions such that the patch will be executed only when the conditions are true at the time of execution.
  • In addition to significantly reducing the time needed to create source code, the [0041] Code Patcher system 133 can be used for a variety of other purposes. For example, an executable code file may have been incomplete when compiled. In this situation, references to symbols (e.g., variables or functions) may have been stubbed at the time of compilation. The Code Patcher system 133 can be used to replace the stubs with references to code fragment executables. In addition, additional functionality can be added even to compiled executable code files that lack errors. For example, a graphical user interface could be added to an executable code file with only a command-line interpreter, or new functionality can be added to handle inputs or situations not anticipated at the original time of compilation. Those skilled in the art will appreciate that any such type of functionality can be added using the Code Patcher system 133. Those skilled in the art will also appreciate that computer systems 100 and 150 are merely illustrative and are not intended to limit the scope of the present invention. The computer systems may contain additional components or may lack some illustrated components. Accordingly, the present invention may be practiced with other computer system configurations, including a single computer system.
  • As an illustrative example of patching compiled executable code, consider FIGS. 2A and 2B. FIG. 2A illustrates sequences of compiled instructions from a compiled executable code file. For readability, a corresponding source code line is shown for each instruction. Those skilled in the art will appreciate that the particular source code lines are merely illustrative. FIG. 2B illustrates the same compiled executable code file after various patches have been added. In particular, five patches, including a code fragment executable module, have been added to the original compiled executable code file. [0042]
  • [0043] Patch 1 demonstrates a patch that adds a trace request before instruction N. As is shown in FIG. 2B, instruction N is replaced in the compiled executable code file with a patching instruction that indicates to transfer flow of execution to a patch handler for Patch 1. When execution is transferred to the patch handler for Patch 1, the patch handler first saves the current state of the target system on which execution is occurring. The patch handler then issues a trace request for a designated string of information. The original patched instruction, instruction N, is then executed in the patch handler.
  • Thus, [0044] Patch 1 executes the trace request in addition to, rather than substituted for, the replaced instruction N. After executing instruction N, the original state of the computer system is then restored before the flow of execution is returned to instruction N+1. Those skilled in the art will appreciate that an execution such as the trace request can be performed in a variety of ways, such as by writing the specified information to a file or by sending the information to another computer, such as in a message object or as text in an email message. Alternately, trace information can be output using any other communication means (e.g., pager, cellular phone, display device, etc.). Note that although the trace request in Patch 1 did not include any variables or expressions to be evaluated, instruction N will require the evaluation of the variables a and c. This evaluation will occur in the context of the appropriate current variable scope.
  • [0045] Patch 2 reflects a patch which replaces instruction N+3 with multiple patch statements, including both a trace request and a code fragment executable. Patch 2 also demonstrates a patch that substitutes for an existing instruction rather than adding patch statements, and thus existing instruction N+3 will be not executed in the patched executable code file. When flow of execution is transferred to the patch handler for Patch 2, the patch handler first saves the current target computer system state. The patch handler then executes the trace request and the code fragment executable as shown. Note that this trace request will require the evaluation of variable a, which will be performed in the context of the appropriate current variable scope. The code fragment executable will be executed in an interpreted manner. After executing the various instructions in the patch handler, the original computer system state is restored before returning flow of execution to instruction N+4.
  • As is shown in FIG. 2B, the code fragment executable module labeled FN[0046] 2 has also been added as part of the patch process. Patch 3 adds patch statements before instruction N+6, including a call to the newly created module. Patch 3 also illustrates that multiple code statements can be executed within a patch handler (limited only by available memory on the target computer system). After flow of execution transfers to the patch handler for Patch 3, the appropriate computer system state is first saved. Next, the code fragment executable for the code statement ‘b=b−1’ is executed in an interpreted manner. The next patch statement calls module FN2 with the variable b as a parameter. Flow of execution will then transfer to the code fragment executable for module FN2, at which time instructions M, M+1, and M+2 will be executed in sequence in an interpreted manner. Upon execution of the return statement in instruction M+2, the flow of execution will return to instruction N+6 in the patch handler for Patch 3. After restoring state for Patch 3, the flow of execution will return to instruction N+7 in the patched compiled executable code file. Those skilled in the art will appreciate that each of the patch handlers can return flow of execution to the compiled instructions in a variety of ways, such as using a return statement or explicitly using the memory location of the next compiled instruction. In addition, in one embodiment each code statement has a separate code fragment executable, while in another embodiment the various code statements in a patch handler are combined into a single code fragment executable.
  • Finally, [0047] Patch 4 illustrates that compiled functions can be patched and traced in a manner similar to that of any other compiled instruction. For example, if a user desires to trace all invocations of the function FN1, Patch 4 can be added before the first instruction of the function, instruction P. The trace requests in Patch 4 illustrate that when the variable X is evaluated, it will be evaluated using the current variable scope of function FN1, but that the global variable Y will be evaluated using the appropriate variable scope for Y, which may be the entire program rather than the local scope of function FN1. Those skilled in the art will appreciate that a variety of other patches are possible.
  • Referring now to FIGS. 3A and 3B, illustrative examples of code fragment executables stored in an executable machine-independent non-compiled format are shown. In particular, the exemplary machine-independent format shown are parse trees. In FIG. 3A, the source code statement ‘A=A+(B*3)’ is shown, along with a corresponding parse tree that encodes this source code statement. The original source code line can be reconstructed by using depth-first search along the parse tree, using non-leaf nodes only after the first child branch has been used. Similarly, FIG. 3B illustrates a possible parse tree for the source code function Swap as shown. As the parse tree is read from left to right and upwards from the leaf nodes, the appropriate order of statements for the Swap function is retrieved. Those skilled in the art will appreciate that a parse tree can be represented using different formats, and that parse trees are only one possible format for encoding executable machine-independent code fragment executables. [0048]
  • FIG. 4 is an exemplary flow diagram of an embodiment of the [0049] Command Subsystem routine 400. The Command Subsystem routine will receive a command from a user to either patch a compiled executable code file such as code file 132 or to execute an already patched executable code file such as patched code file 182. In an alternate embodiment, patches can be added to a compiled executable code file that already contains patches (and can even patch already patched instructions), as well as to a compiled executable code file without patches. If the user is currently patching a compiled executable code file, the routine will accept a variety of trace requests and code fragments to be added to the code file, will combine multiple patches if they are to be added at the same compiled instruction in the compiled executable code file, and will notify the Patching Subsystem 136 (FIG. 1) and the Code Fragment Executables Subsystem 138 (FIG. 1) of the patches. If the user is executing an already patched executable code file, the routine can receive commands, relay them to the Patch Interpreter Subsystem 181(FIG. 1), and receive and display to the user the results of the execution of the command. In one embodiment in which the Command Subsystem 134 (FIG. 1) provides interactive control over a patched executable code file, a user can determine whether or not to view the source code for patches (e.g., not viewing source code for disabled patches).
  • The Command Subsystem routine begins at [0050] step 405 where a command is received from a user. The routine continues in step 410 to determine if the command is to patch a compiled executable code file. If so, the routine continues to step 415 where it receives an indication of the executable code file to be patched. The routine then continues in step 420 to load information from the symbol table of the indicated executable code file, thus allowing the source code lines corresponding to the compiled executable code instructions to be displayed to the user. The routine then continues to step 425 where a request is received from the user that is related to patching the compiled executable code file. The routine continues in step 430 to execute the Process Patch Request subroutine to process the request. As is explained in greater detail with relation to FIG. 5, possible patch requests include adding various trace requests or code fragments, grouping and degrouping patches, and manipulating previously created patches. After the patch request has been processed in step 430, the routine continues in step 435 to determine if there are more patch requests from the user. If so, the routine returns to step 425 to receive the next patch request.
  • If there are not more patch requests from the user, the routine continues to step [0051] 440 to sequence patches together when they will replace the same compiled instruction. Since any given compiled instruction in the compiled executable code file can only be replaced with a single patching instruction to a patch handler, multiple patches that have been associated with a single compiled instruction must be sequenced together. Additional steps may also need to be taken to ensure that all patches are executed and that the correct order of patch execution is followed. In the illustrated embodiment, multiple patches associated with a single compiled instruction are placed in a single patch handler for the patching instruction that will replace the compiled instruction. Alternately, multiple patch handlers could be used, with each patch handler transferring flow of execution to the next patch handler in sequence and with the last patch handler returning the flow of execution to the compiled instruction following the patching instruction. In either case, a sequence in which to execute the multiple patches must be selected. For example, all trace requests could be executed either before or after all code fragments. In the illustrated embodiment, the user indicates the sequence of patches when the patches are created.
  • After [0052] step 440, the routine continues to step 445 to notify the Patching Subsystem 136 of the patch sequences to be added to the compiled executable code file, including sequences of a single patch. The routine then continues to step 450 to notify the Code Fragment Executables Subsystem 138 of the code fragments, including created modules, that have been added as patches to the compiled executable code file. The routine continues in step 455 to determine if there are more commands from the user. If so, the routine returns to step 405 to receive a user command, and if not, the routine ends at step 499.
  • If it is instead determined in [0053] step 410 that the received user command is not to patch a compiled executable code file, the routine continues to step 460 where an indication of a patched compiled executable code file is received. This patched code file will be executed on an indicated target computer system. In the illustrated embodiment, the patched code and any associated patch handlers and code fragment executables will have been transferred to the indicated target system when the patching occurred. Alternately, the transferring could occur after step 460. The routine next continues to step 465 to determine if the patched code file is to be executed with interactive control by the user. If the patched executable code file is not to be executed interactively, the routine continues to step 470 where the Patch Interpreter Subsystem 181 is notified to execute the patched executable code file without waiting for interactive commands. If instead it is determined in step 465 that the patched executable code file is to be executed interactively, the routine continues instead to step 475 where the Patch Interpreter Subsystem 181 is notified to execute the patched executable code file in an interactive execution mode.
  • The routine next continues to step [0054] 480 to receive an execution-related command from the user. Such commands could include setting or removing break points, checking the current values of variables and expressions, or stepping through the execution a single line at a time. In the illustrated embodiments, the manipulation of patches does not occur during interactive execution, but such functionality could be provided in an alternate embodiment. In step 485, the routine notifies the Patch Interpreter Subsystem 181 of the command, and in step 490 the results of the command execution are received from the Patch Interpreter Subsystem 181 and are displayed to the user. The routine then continues to step 495 to determine if there are more interactive execution commands from the user. If so, the routine returns to step 480 to receive the next user command. After step 470, or if it is determined in step 495 that there are not more interactive execution commands, the routine continues to step 455 to determine if there are more user commands. Those skilled in the art will appreciate that the Command Subsystem routine can be implemented in a variety of ways. For example, other top-level user commands than patching compiled executable code files and executing patched compiled executable code files could be processed by the routine. Alternately, separate routines could be used to patch a compiled executable code file and to execute a patched compiled executable code file.
  • FIG. 5 is an exemplary flow diagram of an embodiment of the Process [0055] Patch Request subroutine 430. The Process Patch Request subroutine receives a user request related to patching the compiled executable code file, determines the type of patch request, and satisfies the patch request. In the illustrated embodiment, the user indicates source code lines corresponding to compiled instructions in the compiled executable code file for patch requests, and the Code Patcher system 133 selects the appropriate compiled instruction for the indicated source code line when performing the request.
  • The subroutine begins at [0056] step 505 where it is determined if the patch request is to add a trace request to indicate when a source code line is executed. If so, the subroutine continues to step 510 to add the trace request to an appropriate patch handler, which will be referenced by a patching instruction that replaces a compiled instruction corresponding to the indicated source code line. If it is instead determined that the trace request is not to trace a source code line, the subroutine continues to step 515 to determine if the patch request is to add a trace request to indicate when a function in the compiled executable code file is executed. If so, the subroutine continues to step 520 to add a trace request to a patch handler for the first instruction of the indicated function. If the patch request is not to trace a function, the subroutine continues to step 525 to determine if the patch request is to add a trace request for a specified expression at a particular source line. If so, the subroutine continues to step 530 to add a trace request for the expression to a patch handler at the indicated source line. If the patch request is not to trace a specified expression, the subroutine instead continues to step 535 to determine if the patch request is to add a specified code fragment to the compiled executable code file. If so, the subroutine continues to step 540 to add the specified code fragment executable to a patch handler at the compiled instruction corresponding to an indicated source line. The user can also indicate whether the patch is to substitute for the instruction or to be added in addition to the instruction, and when the patch is added in addition to the instruction whether the patch is to be executed before or after the source code line.
  • If it has been determined in [0057] steps 505, 515, 525, and 535 that the patch request is not to add to the compiled executable code file patch statements that require patch handlers, the subroutine continues to step 545 to determine if the patch request is to create a code fragment module. If so, the subroutine continues to step 550 where an invokable code module with multiple source code statements is specified by the user, and an associated code fragment executable module is created for the patched executable code file. If it is determined in step 545 that the patch request is not to create a code module, then the subroutine continues to step 555 to determine if the patch request is to group patches together or to degroup previously grouped patches into individual patches. If so, the subroutine continues to step 560 to perform the indicated grouping or degrouping. If the patch request is not to group or degroup patches, the subroutine continues to step 565 to determine if the patch request is to manipulate a patch or patch group. If so, the subroutine continues in step 570 to manipulate the patch or the patches in a patch group as indicated. After step 510, 520, 530, 540, 550, 560, or 570, or if it is determined in step 565 that the patch request does not manipulate a patch or a patch group, the subroutine continues to step 590 where it returns.
  • FIG. 6 is an exemplary flow diagram of an embodiment of the [0058] Patching Subsystem routine 600. The Patching Subsystem routine is notified by the Command Subsystem routine when patch sequences are to be added or manipulated for a compiled executable code file. The Patching Subsystem routine then creates the necessary patch handlers, patches the compiled executable code file in the appropriate manner, and loads the patch handlers and the patched compiled executable code file onto a target system. The routine begins at step 605 where one or more patch sequences are received for a compiled executable code file. This notification from the Command Subsystem 134 can also indicate that previously added patches have been manipulated (e.g., removed or disabled). The routine continues in step 610 to select the next received patch sequence to be added or manipulated, beginning with the first received patch sequence. The routine then continues to step 615, where an appropriate patch handler is created if the selected patch sequence indicates that a patching instruction is to be added to the compiled executable code file. Alternately, if an existing patch is being changed, an existing patch handler can be accordingly modified or a new patch handler can be created to replace an existing patch handler. For example, if a previously added patch is being removed, the original patched instruction can be reinserted in the compiled executable code file in place of the patching instruction. Alternately, if a patch handler is being disabled, the first instruction of the patch handler could be modified to cause a jump to the end of the patch handler or to the instruction following the patching instruction. Similarly, if a patch is being qualified, the patch handler for that patch can be modified to include evaluation statements to determine if the specified conditions are true.
  • After [0059] step 615, the routine continues to 620 to, if a patching instruction needs to be added, replace the appropriate compiled executable code instruction with a patching instruction (e.g., a jump statement) to the created patched handler. If an existing patch handler is merely being modified, it will not be necessary to replace a compiled instruction with a patching instruction since the existing patching instruction will still be effective. While the illustrated embodiment uses a jump instruction for patching instructions, those skilled in the art will appreciate that a patch handler can be invoked in a variety of ways, such as by using an interrupt mechanism or by including an identifier that will be resolved at execution time to indicate an appropriate location in memory on the target system. In addition, those skilled in the art will appreciate that a compiled transfer statement instruction could be used as a patching instruction. After step 620, the routine continues in step 625 to determine if there are more patch sequences to be selected. If so, the routine returns to step 610 to select the next patch sequence, and if not, the routine continues to step 630.
  • After patch handlers have been created or modified for each patch sequence and patching instructions have been added to the compiled executable code file, the routine in [0060] step 630 loads the patched executable code file onto the target system. The routine then continues in step 635 to load any created and/or modified patch handlers onto the target system. In the illustrated embodiment, the Patching Subsystem 136 does not perform memory management for target computer system 150, so the memory locations on the target system in which the created patch handlers will be loaded will not be known until execution time. Thus, the patching instructions inserted into the compiled executable code file merely reference the appropriate patch handler, with the reference to the appropriate memory location to be resolved at execution time. This type of reference resolution allows linking to be delayed until execution time. Thus, after step 635, the routine continues in step 640 to update a Link Translation Table on the target system to reflect the unique identifiers for the created patch handlers. After step 640, the routine continues to step 645 to determine if there are more patch sequences to receive. If so, the routine returns to step 605 to receive patch sequences, and if not the routine continues to step 690 and ends.
  • FIG. 7 is an exemplary flow diagram of an embodiment of the Code Fragment Executables Subsystem routine [0061] 700. The Code Fragment Executables Subsystem routine receives notifications from the Command Subsystem 134 when code fragments are to be added to the compiled executable code file, creates machine-independent non-compiled code fragment executables that can be interpreted by the Patch Interpreter Subsystem 181, and loads the created code fragment executables onto the target system. The routine begins in step 705 where code fragments to be added to the compiled executable code file are received from the Command Subsystem. The routine continues to step 710 to select the next code fragment, beginning with the first code fragment. In step 715, the routine then creates a code fragment executable for the selected code fragment in a machine-independent format not specific to the target computer. In the illustrated embodiment, the code fragment executables are stored in parse tree format. The routine then continues in step 720 to determine if there are more code fragments to process. If so, the routine returns to step 710 to select the next code fragment, and if not the routine continues to step 725.
  • After the code fragment executables have been created, the routine in [0062] step 725 loads the created code fragment executables onto the target system. The routine then continues to step 730 to update the Link Translation Table on the target system to reflect the references for the created code fragment executables. For example, if invokable code modules have been created for the patched compiled executable code file, an entry in the Link Translation Table can be used to resolve at execution time a reference to a code module, allowing flow of execution to be transferred to the appropriate memory location where the code fragment executable for the module is loaded in memory. Similarly, if variables have been defined and made available to other portions of the code outside a self-contained variable scope (e.g., global variables), the Link Translation Table can be used to resolve references to those variables by other portions of the code. Finally, if the code fragment executables are loaded into memory separate from the patch handlers that will reference those code fragment executables, then the Link Translation Table can be used to resolve the references for each such code fragment executable.
  • Those skilled in the art will appreciate that if the memory locations for code fragment executables are known at the time that the patches and patch handlers are created, it may not be necessary to use a Link Translation Table to resolve those references. For example, if code fragment executables are included with the patch handlers which reference them, then each such code fragment executable would not need a unique identifier that could be resolved through the use of the Link Translation Table. After [0063] step 730, the routine continues in step 735 to determine if there are more code fragments to receive. If so, the routine returns to step 705, and if not the routine ends at step 790.
  • FIG. 8 is an exemplary flow diagram of an embodiment of the Patch Interpreter Subsystem routine [0064] 800. The Patch Interpreter Subsystem routine receives an indication of a patched executable code file to be executed, loads the patched compiled executable code file as well as associated patch handlers and code fragment executables into memory, executes the non-patched compiled instructions as native code for the target system, and executes the patch statements in an interpreted manner. Those skilled in the art will appreciate that in an alternate embodiment, before execution time the Patch Interpreter Subsystem 181 or another subsystem could compile the target-independent code fragment executables into compiled instructions that are native to the particular target system. In this situation, the Patch Interpreter Subsystem 181 would only be needed to resolve references, such as for patch handlers and code fragment executable modules, when such references are included in the patched compiled executable code file.
  • The routine begins in [0065] step 805 where an indication is received of the patched executable code file to be executed. In the illustrated embodiment, this indication is received from the Command Subsystem 134 on the host computer system. In an alternate embodiment, the Patch Interpreter Subsystem 181 could receive instructions directly from a user on the target computer system if the target system included the necessary input/output devices. The routine then continues to step 810 to load the patch handlers and code fragment executables associated with the patched compiled executable code file into memory if they are not already stored in memory. The routine then continues to step 815 to ensure that the Link Translation Table reflects the current memory addresses for the code fragment executables and the patch handlers. After step 815, the routine continues to step 820 where the patched compiled executable code file is loaded into memory if it is not already stored in memory. The routine then continues to step 825 to execute the Execute Patched Executable Code subroutine. The routine then continues to step 830 to determine if there are more patched compiled executable code files to execute. If so, the routine returns to step 805, and if not, the routine ends at step 890. Those skilled in the art will appreciate that in an alternate embodiment, the Patch Interpreter Subsystem routine could execute multiple different patched executable code files at the same time.
  • FIG. 9 is an exemplary flow diagram of an embodiment of the Execute Patched [0066] Executable Code subroutine 825. The Execute Patched Executable Code subroutine receives and executes user commands if an interactive execution of the patched compiled executable code file is in process. When a non-patched compiled instruction is to be executed, it is executed as native code. For each patch statement, the subroutine first determines if the statement is to be executed and then resolves link identifiers if necessary. The subroutine then satisfies trace requests by writing the specified trace information to a trace log on the target system, executes code fragment executables by interpreting them, and notifies the Code Patcher system 133 of the execution status after the instruction has been processed.
  • The subroutine begins at [0067] step 905 where it is determined if the current execution of the patched compiled executable code file is to be done in an interactive mode. If so, the routine continues in step 910 to receive a user command. The subroutine then continues to step 915 to determine if the received command is to execute the current instruction in the patched executable code file. If not, the subroutine continues to step 920 to execute the user command, and then continues to step 925 to notify the Code Patcher system 133 of the results of executing the command. For example, a user may wish to see a current value for a variable or to specify a break point at a spot in the patched compiled executable code file. After such a break point has been set, the user may indicate to continue execution in a non-interactive mode until a break point is reached, thus causing execution to stop and returning execution of the patched executable code file to an interactive mode. After step 925, the subroutine returns to step 905.
  • If it was instead determined in [0068] step 905 that the execution of the patched executable code file is not currently in interactive mode, or if it was determined in step 915 that the user command was to execute the current instruction, the subroutine continues in step 930 to select the next instruction in the patched executable code file, beginning with the first instruction. The subroutine then continues to step 931 to determine whether the current instruction is to be currently executed. For example, the current instruction could be a patching instruction for a patch that is disabled or that is qualified with a condition that is not currently met in the current environment. If the instruction is not to be currently executed, the subroutine continues to step 970 where the Code Patcher system 133 will be notified of the status of execution of the current instruction if execution is occurring in an interactive mode. Those skilled in the art will appreciate that when an entire patch handler consisting of multiple patch statements has been disabled or is not qualified, the status of the patch handler can be indicated in a variety of ways. For example, a flag could be set when the patch handler was entered indicating that patch statements are not to be currently executed while the flag is set, with the flag being reset when the end of the patch handler is reached. Alternately, the patch handler could cause the flow of execution to skip any disabled patch statements.
  • If it is determined in [0069] step 931 that the current instruction is to be executed, the subroutine continues to step 932 to determine if the instruction is a compiled instruction. If so, the subroutine continues to step 933 to execute the current instruction in native mode on the target system, and then continues to step 970. If it is instead determined in step 932 that the current instruction is a non-compiled patch statement or patching instruction, the subroutine continues in step 935 to determine if the current instruction includes a link identifier reference that needs to be resolved. If so, the subroutine continues in step 940 to use the Link Translation Table to resolve the link identifier so that the current position in memory for the associated code can be accessed. After step 940, or if it is determined in step 935 that a link identifier is not present, the subroutine continues in step 945 to determine if the current instruction is a trace request. If so, the subroutine continues to step 950 to write the specified trace information to a trace log on the target system that can be retrieved by a user on the host computer system 100. If the trace request includes variable or expressions to be evaluated, they will be evaluated in the context of the current variable scope.
  • If it is instead determined in [0070] step 945 that the current instruction is not a trace request, the subroutine continues to step 965 to execute the code fragment executable by interpreting it within the context of the current variable scope. For example, a global variable X may be defined, with the current flow of execution first entering Function 1 with a variable X that is local to that function and then entering a Function 2 with a distinct local variable X for that function. If patch code within Function 2 requires the evaluation of variable X, its current variable binding within the scope of Function 2 will be used for the evaluation. Those skilled in the art will appreciate that the current variable scope can be determined in a variety of ways, such as by using symbol table information from the patched executable code file or the current variable block on the stack. After step 950 or 965, the subroutine continues at step 970 to notify the Code Patcher system 133 of the status of executing the current instruction if execution is occurring in interactive mode. The subroutine then continues to step 975 to determine if there are more instructions to be executed in the patched compiled executable code file. If so, the subroutine returns to step 905, and if not the subroutine returns in step 990.
  • From the foregoing it will be appreciated that, although specific embodiments of the invention have been described herein for purposes of illustration, various modifications may be made without deviating from the spirit and scope of the invention. Accordingly, the invention is not limited except as by the appended claims. [0071]

Claims (52)

1. A method for modifying an executable file including a plurality of compiled instructions, the compiled instructions natively executable on a target computer but not on a source computer, the modifying performed under control of the source computer without recompiling or relinking or rewriting the executable file, the method comprising:
under control of the source computer,
(a) loading the executable file onto the target computer;
(b) receiving a plurality of indications to modify the loaded executable file, each indication specifying one of the compiled instructions in the loaded executable file and at least one non-compiled executable instruction to be added to the loaded executable file;
(c) modifying the loaded executable file by, for each indication,
creating an instruction group including the specified at least one non-compiled executable instruction;
converting the instruction group into an executable non-compiled format not specific to the target computer; and
replacing the specified compiled instruction in the loaded executable file with an executable patch instruction associated with the converted instruction group, the patch instruction when executed to transfer flow of execution to the converted instruction group with which the patch instruction is associated; and
(d) loading the converted instruction groups into at least one memory area on the target computer, the at least one memory area distinct from a memory area on the target computer containing the loaded executable file; and
under control of the target computer, executing the modified loaded executable file by, as the flow of execution sequentially reaches each executable instruction,
(e) when the executable instruction is a non-compiled executable instruction from an instruction group, interpretively evaluating the executable instruction;
(f) when the executable instruction is a patch instruction, transferring flow of execution to the loaded associated converted instruction group; and
(g) when the executable instruction is a compiled instruction, natively executing the compiled executable instruction,
so that additional functionality is exhibited when the modified loaded executable file is executed on the target computer.
2. The method of claim 1 wherein at least one of the non-compiled executable instructions is a trace instruction specifying information related to execution of the loaded executable file, and wherein when the flow of execution reaches the trace instruction a current state of the specified information is made available to the source computer.
3. The method of claim 2 wherein at least one of the instruction groups includes the specified compiled instruction that was replaced with the patch instruction associated with that instruction group.
4. The method of claim 1 wherein when multiple indications specify a single compiled instruction a single instruction group is created for the multiple indications, the single instruction group including the non-compiled executable instructions specified by each of the multiple indications.
5. The method of claim 1 wherein the patch instructions are transfer statements.
6. The method of claim 1 wherein the executable non-compiled format is a parse tree.
7. The method of claim 1 wherein when a non-compiled executable instruction is interpretively evaluated, references to variables are resolved using a current variable scope created by compiled instructions.
8. The method of claim 1 wherein after performing steps (a)-(g) a first time, steps (b)-(g) are performed a second time without performing step (a) a second time such that the modified loaded executable file is further modified and then executed without reloading the executable file.
9. A method for modifying a compiled file loaded on a target computer, the loaded compiled file including a plurality of instructions executable on the target computer, the method comprising:
modifying the loaded compiled file by,
under control of a source computer,
receiving an indication to modify the loaded compiled file by adding at least one instruction to be executed upon execution of the loaded compiled file;
creating a patch group including a plurality of instructions, the plurality of instructions including the indicated at least one instruction; and
replacing an instruction in the loaded compiled file with a patch instruction; and
loading the patch group into a first portion of memory on the target computer distinct from a second portion of memory on the target computer containing the loaded compiled file; and
on the target computer, executing the instructions in the modified loaded compiled file by, when an instruction to be executed is the patch instruction, indicating one of the plurality of instructions in the loaded patch group as a next instruction to be executed.
10. The method of claim 9 wherein the indicating of the one of the plurality of instructions involves transferring flow of execution to a first instruction in the loaded patch group.
11. The method of claim 10 wherein the plurality of instructions in the compiled file are in a compiled format specific to the target computer, wherein the plurality of instructions in the loaded patch group are in a non-compiled format not specific to the target computer, and wherein when an instruction to be executed is one of the plurality of instructions in the loaded patch group, the instruction is executed by interpreting the instruction.
12. The method of claim 11 wherein the non-compiled format is a parse tree.
13. The method of claim 10 wherein the patch group includes a return instruction that when executed transfers flow of execution back to an instruction in the loaded modified compiled file.
14. The method of claim 10 wherein the patch instruction is a transfer statement.
15. The method of claim 9 wherein the created patch group includes the replaced instruction.
16. The method of claim 9 wherein the indicated at least one instruction specifies that information related to execution of the loaded compiled file be provided for a user.
17. The method of claim 16 wherein when flow of execution reaches the indicated at least one instruction a current state of the specified information is determined using a current variable scope.
18. The method of claim 9 wherein the executing of the instructions in the modified loaded compiled file on the target computer is performed under interactive control of the source computer.
19. The method of claim 9 including before the modifying of the loaded compiled file, loading the compiled file into the second portion of memory.
20. The method of claim 19 including after the modifying of the loaded compiled file and the executing of the instructions in the modified loaded compiled file, performing the modifying and the executing again without performing the loading of the compiled file into memory again.
21. The method of claim 9 including:
halting the executing of the instructions in the modified loaded compiled file before the executing has completed;
performing the modifying of the loaded compiled file again; and
continuing the halted executing without restarting execution of the modified loaded compiled file.
22. A computer-implemented method for adding instructions to be executed to an executable compiled file without recompiling or rewriting the file, the method comprising:
receiving an indication to modify the compiled file, the indication specifying a compiled instruction in the compiled file and at least one executable instruction to be added;
modifying the compiled file by,
creating a patch group including the specified at least one executable instruction; and
replacing the specified compiled instruction in the compiled file with a patch instruction such that flow of execution will transfer to the created patch group upon execution of the patch instruction, and
storing separate from the patch group the modified compiled file including the patch instruction,
so that instructions in the patch group will be executed when the modified compiled file is later executed.
23. The method of claim 22 wherein the instructions in the patch group are in a non-compiled format such that execution of the instructions involves interpreted evaluation.
24. The method of claim 22 wherein the created patch group includes a return instruction that when executed transfers flow of execution back to an instruction in the modified compiled file.
25. The method of claim 22 wherein the created patch group includes the replaced instruction.
26. The method of claim 22 wherein the specified at least one executable instruction will when executed provide trace information about current execution of the modified file.
27. The method of claim 26 wherein the trace information indicates when the specified compiled instruction is executed.
28. The method of claim 26 wherein the trace information indicates when a function including the specified compiled instruction is invoked.
29. The method of claim 22 wherein a plurality of executable instructions to be added are specified and wherein the created patch group includes a function with multiple instructions, the function invokable by other instructions.
30. The method of claim 22 wherein the modified compiled file is executed on a separate computer, and including:
supplying to the separate computer at least one direction related to the execution of the modified compiled file; and
displaying received results of performance of the supplied direction.
31. The method of claim 22 wherein without removing the patch instruction from the modified compiled file, the patch group is disabled such that the instructions in the patch group are not executed when the modified compiled file is executed.
32. A computer-implemented method for executing a modified compiled file including a plurality of original compiled instructions and at least one patch instruction in place of an original compiled instruction, each patch instruction when executed to transfer flow of execution to an associated patch group including a plurality of instructions, the method comprising:
loading the modified compiled file and the associated patch groups into memory; and
executing the modified compiled file by, as the flow of execution reaches each executable instruction,
when the executable instruction is an original compiled instruction, natively executing the executable instruction;
when the executable instruction is one of the patch instructions, transferring flow of execution to the associated patch group for the patch instruction; and
when the executable instruction is one of the plurality of instructions from a patch group, interpretively evaluating the executable instruction.
33. The method of claim 32 wherein the modified compiled file is loaded into memory on a target computer and wherein the plurality of instructions in the loaded patch groups are in a non-compiled format not specific to the target computer.
34. The method of claim 33 wherein the patch groups are loaded into memory on a source computer distinct from the target computer.
35. The method of claim 32 wherein a location in memory is determined for each patch group when the patch group is to be loaded, wherein the memory location of each loaded patch group is tracked, and wherein when a patch instruction is to be executed, the tracked current memory location of the associated patch group is determined to enable the transferring of the flow of execution.
36. The method of claim 32 wherein before each patch group is loaded into memory, a memory location is predetermined for the patch group and the patch instruction for the patch group indicates the predetermined memory location, the predetermined memory location to be used for the transferring of the flow of execution.
37. The method of claim 32 wherein the plurality of instructions in the loaded patch groups are specified in a non-compiled format.
38. The method of claim 32 wherein when interpretively evaluating instructions from a patch group, variables are evaluated in the context of current variable scopes.
39. The method of claim 32 wherein the executing of the modified compiled file is performed under interactive control of a distinct computer.
40. A computer system for adding instructions to be executed to an executable compiled file without recompiling or rewriting the file, comprising:
a command subsystem for receiving indications to modify the compiled file, each indication specifying a compiled instruction in the compiled file and at least one executable instruction to be added; and
a patching subsystem for modifying the compiled file by creating for each received indication an associated patch group including the specified at least one executable instruction, and by replacing the specified compiled instruction in the compiled file with a patch instruction such that flow of execution will transfer to the associated patch group upon execution of the patch instruction.
41. The computer system of claim 40 including a code fragment executables subsystem for converting instructions in the patch group into a non-compiled format such that execution of the instructions involves interpreted evaluation.
42. The computer system of claim 40 wherein the modified compiled file is executed on a separate computer, and wherein the command subsystem is further for receiving an indication to supply to the separate computer at least one direction related to the execution of the modified compiled file and for displaying received results of performance of the supplied direction.
43. The computer system of claim 40 wherein the specified at least one executable instruction will when executed provide trace information about current execution of the modified file.
44. The computer system of claim 40 including a patch interpreter subsystem for executing the modified compiled file by, as the flow of execution reaches each executable instruction,
when the executable instruction is a compiled instruction, natively executing the executable instruction;
when the executable instruction is one of the patch instructions, transferring flow of execution to the associated patch group for the patch instruction; and
when the executable instruction is one of the instructions from a patch group, interpretively evaluating the executable instruction.
45. A computer-readable medium containing instructions for controlling a computer system to add instructions to be executed to an executable compiled file without recompiling the file, by:
receiving an indication to modify the compiled file, the indication specifying a compiled instruction in the compiled file and at least one executable instruction to be added; and
modifying the compiled file by,
creating a patch group including the specified at least one executable instruction; and
replacing the specified compiled instruction in the compiled file with a patch instruction such that flow of execution will transfer to the created patch group upon execution of the patch instruction.
46. The computer-readable medium of claim 45 wherein the instructions in the patch group are in a non-compiled format such that execution of the instructions involves interpreted evaluation.
47. The computer-readable medium of claim 45 wherein the modified compiled file is executed on a computer separate from the controlled computer system, and wherein the controlled computer system is further controlled by:
supplying to the separate computer at least one direction related to the execution of the modified compiled file; and
displaying received results of performance of the supplied direction.
48. The computer-readable medium of claim 45 wherein the specified at least one executable instruction will when executed provide trace information about current execution of the modified file.
49. The computer-readable medium of claim 45 wherein the computer system is further controlled to execute the modified compiled file by, as the flow of execution reaches each executable instruction,
when the executable instruction is a compiled instruction, natively executing the executable instruction;
when the executable instruction is one of the patch instructions, transferring flow of execution to the associated patch group for the patch instruction; and
when the executable instruction is one of the instructions from a patch group, interpretively evaluating the executable instruction.
50. The computer-readable medium of claim 45 wherein the computer system is further controlled by, before the modifying of the compiled file, loading the compiled file into memory of a second computer system, and wherein the modifying of the compiled file modifies the loaded compiled file such that the specified compiled instruction is replaced in the loaded compiled file.
51. The computer-readable medium of claim 45 wherein the computer system is further controlled by, after the modifying of the compiled file executing on a target computer the modified compiled file by, when an instruction to be executed is the patch instruction, indicating an instruction in the created patch group as a next instruction to be executed.
52. The computer-readable medium of claim 51 wherein the computer system is further controlled by, after the executing of the modified compiled file, performing the modifying and the executing again without reloading the compiled file into memory.
US09/212,182 1998-12-14 1998-12-14 Method and system for modifying executable code to add additional functionality Abandoned US20020073398A1 (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
US09/212,182 US20020073398A1 (en) 1998-12-14 1998-12-14 Method and system for modifying executable code to add additional functionality
CA002292123A CA2292123C (en) 1998-12-14 1999-12-08 Method and system for modifying executable code to add additional functionality
EP99310012A EP1014263A3 (en) 1998-12-14 1999-12-13 Method and system for modifying executable code to add additional functionality
JP11355196A JP2000181725A (en) 1998-12-14 1999-12-14 Method and system for altering executable code and giving addition function
US10/369,225 US6948164B2 (en) 1998-12-14 2003-02-18 Method and system for modifying executable code to add additional functionality

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US09/212,182 US20020073398A1 (en) 1998-12-14 1998-12-14 Method and system for modifying executable code to add additional functionality

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US10/369,225 Continuation US6948164B2 (en) 1998-12-14 2003-02-18 Method and system for modifying executable code to add additional functionality

Publications (1)

Publication Number Publication Date
US20020073398A1 true US20020073398A1 (en) 2002-06-13

Family

ID=22789911

Family Applications (2)

Application Number Title Priority Date Filing Date
US09/212,182 Abandoned US20020073398A1 (en) 1998-12-14 1998-12-14 Method and system for modifying executable code to add additional functionality
US10/369,225 Expired - Lifetime US6948164B2 (en) 1998-12-14 2003-02-18 Method and system for modifying executable code to add additional functionality

Family Applications After (1)

Application Number Title Priority Date Filing Date
US10/369,225 Expired - Lifetime US6948164B2 (en) 1998-12-14 2003-02-18 Method and system for modifying executable code to add additional functionality

Country Status (4)

Country Link
US (2) US20020073398A1 (en)
EP (1) EP1014263A3 (en)
JP (1) JP2000181725A (en)
CA (1) CA2292123C (en)

Cited By (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030023955A1 (en) * 2001-07-26 2003-01-30 International Business Machines Corporation Efficient monitoring of program variables under debug
US20030225921A1 (en) * 2002-06-03 2003-12-04 Curl Corporation Software atomization
US20030236794A1 (en) * 2002-06-21 2003-12-25 Curl Corporation Views for software atomization
US6675354B1 (en) 1999-11-18 2004-01-06 International Business Machines Corporation Case-insensitive custom tag recognition and handling
US20040034850A1 (en) * 2000-04-27 2004-02-19 Microsoft Corpaoration Servicing a component-based software product throughout the software product lifecycle
US6718516B1 (en) 1999-09-30 2004-04-06 International Business Machines Corporation Method for verifying context between multiple related XML tags in document object model (DOM)
US6732330B1 (en) 1999-09-30 2004-05-04 International Business Machines Corporation Scripting language blocks to support multiple scripting languages in a single web page
US6745385B1 (en) * 1999-09-01 2004-06-01 Microsoft Corporation Fixing incompatible applications by providing stubs for APIs
US20050034109A1 (en) * 2001-06-04 2005-02-10 Microsoft Corporation Method and system for program editing
US6889260B1 (en) * 1999-06-10 2005-05-03 Ec Enabler, Ltd Method and system for transferring information
US20050141035A1 (en) * 2003-12-04 2005-06-30 Xerox Corporation System and method for processing portions of documents using variable data
US20050268305A1 (en) * 2001-06-07 2005-12-01 Hostetter Mathew J Software atomization
US6973417B1 (en) 1999-11-05 2005-12-06 Metrowerks Corporation Method and system for simulating execution of a target program in a simulated target system
US6981212B1 (en) 1999-09-30 2005-12-27 International Business Machines Corporation Extensible markup language (XML) server pages having custom document object model (DOM) tags
US6981211B1 (en) 1999-09-30 2005-12-27 International Business Machines Corporation Method for processing a document object model (DOM) tree using a tagbean
US20060010435A1 (en) * 2001-10-31 2006-01-12 Microsoft Corporation Dynamic software update
US20060015708A1 (en) * 2004-07-14 2006-01-19 Boggs Darrell D Microprocessor with branch target determination in decoded microinstruction code sequence
US20060026403A1 (en) * 2004-07-27 2006-02-02 Texas Instruments Incorporated Compare instruction
US7032213B1 (en) * 1999-09-01 2006-04-18 Microsoft Corporation Fixing incompatible applications using a light debugger
US20060265692A1 (en) * 2005-05-20 2006-11-23 Mengjin Su Method, apparatus, and computer program product for code patching
US7228527B1 (en) * 2003-07-15 2007-06-05 Hewlett-Packard Development Company, L.P. Method and system for structuring a procedure
US7266766B1 (en) 1999-09-30 2007-09-04 International Business Machines Corporation Method for developing a custom tagbean
CN100359485C (en) * 2003-07-10 2008-01-02 华为技术有限公司 Testing device and method for flush-bonding system
US20080301402A1 (en) * 2007-06-04 2008-12-04 Sangram Alapati Method and System for Stealing Interrupt Vectors
US20090164982A1 (en) * 2007-12-21 2009-06-25 Sun Microsystems, Inc. Method and system for transforming binaries to use different instructions
US20090249368A1 (en) * 2008-03-25 2009-10-01 Microsoft Corporation Runtime Code Hooking
US7747452B1 (en) * 2002-12-31 2010-06-29 Adams Phillip M Enforcement process for correction of hardware and software defects
US20110035546A1 (en) * 2008-04-11 2011-02-10 Fujitsu Limited Management device and management method
US20110126176A1 (en) * 2009-11-25 2011-05-26 International Business Machines Corporation Providing Programming Support to Debuggers
US20110214110A1 (en) * 2010-02-26 2011-09-01 Red Hat, Inc. Compiler Mechanism for Handling Conditional Statements
US20110258613A1 (en) * 2010-04-15 2011-10-20 International Business Machines Corporation Software debugger activation based on key performance indicators
US8069407B1 (en) * 1998-12-08 2011-11-29 Yodlee.Com, Inc. Method and apparatus for detecting changes in websites and reporting results to web developers for navigation template repair purposes
US20120222010A1 (en) * 2009-11-20 2012-08-30 Zte Corporation Loading and Debugging Method and Debugging System Thereof
US20120265946A1 (en) * 2011-04-12 2012-10-18 Appsense, Limited Bypassing user mode redirection
WO2013050923A1 (en) * 2011-10-03 2013-04-11 International Business Machines Corporation Linking code for an enhanced application binary interface (abi) with decode time instruction optimization
CN103309683A (en) * 2012-03-07 2013-09-18 京信通信系统(中国)有限公司 Software patch embedding method and device for hardware equipment
US8615745B2 (en) 2011-10-03 2013-12-24 International Business Machines Corporation Compiling code for an enhanced application binary interface (ABI) with decode time instruction optimization
US8713547B2 (en) 2011-10-03 2014-04-29 International Business Machines Corporation Generating compiled code that indicates register liveness
US20140282443A1 (en) * 2013-03-13 2014-09-18 Microsoft Corporation Contextual typing
US20140282446A1 (en) * 2013-03-14 2014-09-18 Jeremy Debate Modification of compiled applications and application management using retrievable policies
US20140289455A1 (en) * 2013-03-25 2014-09-25 Dialog Semiconductor B.V. Memory Patching Circuit
US20150160940A1 (en) * 2013-12-09 2015-06-11 Dspace Digital Signal Processing And Control Engineering Gmbh Method for changing the software in the memory of an electronic control unit
US20150277863A1 (en) * 2014-03-31 2015-10-01 International Business Machines Corporation Selectively controlling use of extended mode features
US9348624B2 (en) 2009-07-23 2016-05-24 International Business Machines Corporation Monitoring file access of java processes
WO2016167797A1 (en) * 2015-04-17 2016-10-20 Hewlett Packard Enterprise Development Lp Morphed instruction according to configuration update
US9696974B2 (en) 2013-03-13 2017-07-04 Microsoft Technology Licensing, Llc. Graph-based model for type systems
US9841960B2 (en) * 2015-03-30 2017-12-12 Ca, Inc. Dynamic provision of debuggable program code
US10296447B2 (en) * 2016-12-09 2019-05-21 Fujitsu Limited Automated software program repair
US10599409B2 (en) 2016-02-02 2020-03-24 Blackberry Limited Application lifecycle operation queueing
US10698671B2 (en) 2015-03-30 2020-06-30 Arxan Technologies, Inc. Processing, modification, distribution of custom software installation packages
US10860763B1 (en) * 2015-09-24 2020-12-08 Cadence Design Systems, Inc. Data routing and multiplexing architecture to support serial links and advanced relocation of emulation models
US11150891B2 (en) * 2014-06-10 2021-10-19 Arm Ip Limited Method and device for updating software executed from non-volatile memory
US11301245B2 (en) * 2020-04-24 2022-04-12 International Business Machines Corporation Detecting bias in artificial intelligence software by analysis of source code contributions
US11424931B2 (en) 2016-01-27 2022-08-23 Blackberry Limited Trusted execution environment
CN116737174A (en) * 2023-08-15 2023-09-12 中国兵器装备集团兵器装备研究所 Automatic subsystem generating tool and method based on open source hong Meng system

Families Citing this family (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7475398B2 (en) * 2000-08-01 2009-01-06 Wind River Systems, Inc. System and method for implementing a smart system call
EP1243998B1 (en) * 2001-03-21 2017-04-19 Excalibur IP, LLC A technique for license management and online software license enforcement
JP2002318666A (en) * 2001-04-20 2002-10-31 Hitachi Ltd Update method of firmware of hard disk unit mounted on disk array device and disk array device with function for performing the updating method
US20030005408A1 (en) * 2001-07-02 2003-01-02 Pradeep Tumati System and method for creating software modifiable without halting its execution
US7143407B2 (en) * 2001-07-26 2006-11-28 Kyocera Wireless Corp. System and method for executing wireless communications device dynamic instruction sets
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
US7184759B2 (en) 2001-07-26 2007-02-27 Kyocera Wireless Corp. Modular software components for wireless communication devices
US9554268B2 (en) 2001-07-26 2017-01-24 Kyocera Corporation System and method for updating persistent data in a wireless communications device
US7184793B2 (en) 2001-07-26 2007-02-27 Kyocera Wireless Corp. System and method for over the air area code update
US7200389B2 (en) 2001-07-26 2007-04-03 Kyocera Wireless Corp. Dynamic interface software for wireless communication devices
US7197302B2 (en) 2001-07-26 2007-03-27 Kyocera Wireless Corp. System and method for interchangeable modular hardware components for wireless communication devices
US7027806B2 (en) 2001-07-26 2006-04-11 Kyocera Wireless, Corp. System and method for field downloading a wireless communications device software code section
AU2002319572A1 (en) * 2001-07-26 2003-02-17 Kyocera Wireless Corporation System and method for the management of wireless communications device system software downloads in the field
US7328007B2 (en) 2001-07-26 2008-02-05 Kyocera Wireless Corp. System and method for organizing wireless communication device system software
US7159214B2 (en) 2001-07-26 2007-01-02 Kyocera Wireless Corp. System and method for compacting field upgradeable wireless communication device software code sections
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
US7069546B2 (en) * 2001-12-03 2006-06-27 Corrigent Systems Ltd. Generic framework for embedded software development
JP2004005419A (en) * 2002-03-25 2004-01-08 Canon Inc Install processing apparatus, processing method, storage medium, and program
US7483965B1 (en) 2002-08-19 2009-01-27 Juniper Networks, Inc. Generation of a configuration patch for network devices
US7558835B1 (en) * 2002-08-19 2009-07-07 Juniper Networks, Inc. Application of a configuration patch to a network device
US7865578B1 (en) 2002-08-19 2011-01-04 Juniper Networks, Inc. Generation of a configuration patch for network devices
US7233975B1 (en) 2002-08-19 2007-06-19 Juniper Networks, Inc. Private configuration of network devices
US20040111721A1 (en) * 2002-12-09 2004-06-10 Sun Microsystems, Inc. Method for branch slamming as a safe mechanism for binary code editing
US7124145B2 (en) * 2003-03-27 2006-10-17 Millennium It (Usa) Inc. System and method for dynamic business logic rule integration
US7984434B1 (en) * 2003-05-21 2011-07-19 Altera Corporation Nondestructive patching mechanism
US20050028136A1 (en) * 2003-07-31 2005-02-03 Woodley Ronald Craig System and method for generating an executable procedure
US7359698B2 (en) 2003-09-08 2008-04-15 Kyocera Wireless Corp. Systems and methods for enhanced over-the-air programming
US7318226B2 (en) * 2003-10-16 2008-01-08 International Business Machines Corporation Distributed autonomic solutions repository
US7506241B2 (en) * 2003-10-16 2009-03-17 International Business Machines Corporation Method and apparatus for a self healing agent
US7472384B1 (en) 2003-12-02 2008-12-30 Swsoft Holdings, Ltd. System, method and computer program product for on-the-fly patching of executable code
US7376943B2 (en) * 2003-12-18 2008-05-20 Lsi Corporation Safe method for upgrading firmware of optical disk product
US7523097B1 (en) 2004-01-13 2009-04-21 Juniper Networks, Inc. Restoration of archived configurations for a network device
US8539469B2 (en) 2004-05-11 2013-09-17 Microsoft Corporation Efficient patching
US8869104B2 (en) * 2004-06-30 2014-10-21 Lsi Corporation Object code configuration tool
US7788661B2 (en) * 2005-03-11 2010-08-31 International Business Machines Corporation Method and system for applying patches to a computer program concurrently with its execution
US7506318B1 (en) * 2005-06-28 2009-03-17 Replay Solutions, Inc. Recording and replaying computer programs
US7823153B1 (en) 2005-09-30 2010-10-26 Symantec Corporation System and method for detecting and logging in-line synchronization primitives in application program code
US7930684B2 (en) * 2005-10-12 2011-04-19 Symantec Operating Corporation System and method for logging and replaying asynchronous events
US8117600B1 (en) 2005-12-29 2012-02-14 Symantec Operating Corporation System and method for detecting in-line synchronization primitives in binary applications
US8108851B2 (en) * 2006-01-30 2012-01-31 International Business Machines Corporation External registration for function configuration within a client platform application
US7958497B1 (en) 2006-06-07 2011-06-07 Replay Solutions, Inc. State synchronization in recording and replaying computer programs
US8079019B2 (en) 2007-11-21 2011-12-13 Replay Solutions, Inc. Advancing and rewinding a replayed program execution
US8286238B2 (en) * 2006-09-29 2012-10-09 Intel Corporation Method and apparatus for run-time in-memory patching of code from a service processor
US8201143B2 (en) * 2006-09-29 2012-06-12 Microsoft Corporation Dynamic mating of a modified user interface with pre-modified user interface code library
US8418122B2 (en) * 2006-10-13 2013-04-09 Oracle America, Inc. Incorporating functionality from an object file into an existing binary file
US8683453B2 (en) * 2006-11-30 2014-03-25 Motorola Mobility Llc System for overriding interpreted byte-code with native code
US8285958B1 (en) * 2007-08-10 2012-10-09 Mcafee, Inc. System, method, and computer program product for copying a modified page table entry to a translation look aside buffer
US8347278B2 (en) * 2007-11-02 2013-01-01 International Business Machines Corporation Instrumenting a compiled software routine for augmentation
CN101464791A (en) * 2007-12-17 2009-06-24 鸿富锦精密工业(深圳)有限公司 Code insertion system and method
US8584102B2 (en) * 2007-12-27 2013-11-12 Microsoft Corporation Creating and using deltas to modify existing computer code
US20090249346A1 (en) * 2008-03-27 2009-10-01 Toru Harada Image forming apparatus, information processing apparatus and information processing method
US20090323555A1 (en) * 2008-06-27 2009-12-31 Affinegy, Inc. System and Method for Controlling and Configuring a Router
KR100996632B1 (en) 2008-08-18 2010-11-25 (주)세븐코아 Apparatus and method of dynamically upgrading an execution code image
US8930930B2 (en) 2008-09-04 2015-01-06 International Business Machines Corporation Updating a computer system
US20100088689A1 (en) * 2008-10-03 2010-04-08 Microsoft Corporation Branding binary modules using resource patching
US20100088690A1 (en) * 2008-10-03 2010-04-08 Microsoft Corporation Replacing the identity of an activex control
US8438558B1 (en) 2009-03-27 2013-05-07 Google Inc. System and method of updating programs and data
US8701104B2 (en) * 2009-12-14 2014-04-15 Opera Software Asa System and method for user agent code patch management
US8554797B2 (en) * 2010-12-17 2013-10-08 Sap Ag System and method for modular business applications
US9367298B1 (en) 2012-03-28 2016-06-14 Juniper Networks, Inc. Batch configuration mode for configuring network devices
US9436487B2 (en) * 2012-03-29 2016-09-06 Adobe Systems Incorporated Method and apparatus for creating a platform agnostic application file
GB2503471B (en) * 2012-06-27 2015-05-06 Nordic Semiconductor Asa Integrated-circuit radio
US20150007156A1 (en) * 2013-06-26 2015-01-01 Sap Ag Injecting patch code at runtime
GB2521607B (en) 2013-12-23 2016-03-23 Nordic Semiconductor Asa Integrated-Circuit Radio
US9465768B2 (en) 2014-03-14 2016-10-11 International Business Machines Corporation PCI function measurement block enhancements
US20150370552A1 (en) * 2014-06-20 2015-12-24 Microsoft Technology Licensing, Llc Subscriber defined dynamic eventing
CN105893260A (en) * 2016-03-31 2016-08-24 上海携程商务有限公司 Automatic release system and method for call center
DE102018122920A1 (en) * 2018-09-19 2020-03-19 Endress+Hauser Conducta Gmbh+Co. Kg Method for installing a program on an embedded system, an embedded system for such a method and a method for creating additional information
US11861376B2 (en) * 2022-01-26 2024-01-02 Red Hat, Inc. Live edit of configuration management execution

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4802165A (en) 1986-10-08 1989-01-31 Enteleki, Inc. Method and apparatus of debugging computer programs
JPS63317826A (en) 1987-06-22 1988-12-26 Mitsubishi Electric Corp Symbolic debugging system
JPS6437621A (en) 1987-07-20 1989-02-08 Ibm Updating of program
US5155847A (en) * 1988-08-03 1992-10-13 Minicom Data Corporation Method and apparatus for updating software at remote locations
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
US5450586A (en) 1991-08-14 1995-09-12 Hewlett-Packard Company System for analyzing and debugging embedded software through dynamic and interactive use of code markers
JPH0588880A (en) 1991-09-30 1993-04-09 Nec Corp Debugging system
JPH05241813A (en) 1992-02-28 1993-09-21 Nippon Denki Computer Syst Kk Automatic program addition correction system
JPH06242990A (en) * 1993-02-12 1994-09-02 Fujitsu Ltd Memory patching device
US5481713A (en) 1993-05-06 1996-01-02 Apple Computer, Inc. Method and apparatus for patching code residing on a read only memory device
US5583761A (en) 1993-10-13 1996-12-10 Kt International, Inc. Method for automatic displaying program presentations in different languages
JPH07114487A (en) 1993-10-19 1995-05-02 Mitsubishi Electric Corp Program test device
US5699275A (en) * 1995-04-12 1997-12-16 Highwaymaster Communications, Inc. System and method for remote patching of operating code located in a mobile unit
US5754785A (en) 1995-04-27 1998-05-19 General Datacomm Communications network equipment
US5619698A (en) * 1995-05-05 1997-04-08 Apple Computer, Inc. Method and apparatus for patching operating systems
US5790856A (en) 1995-05-08 1998-08-04 Apple Computer, Inc. Methods, apparatus, and data structures for data driven computer patches and static analysis of same
US5764992A (en) * 1995-06-06 1998-06-09 Apple Computer, Inc. Method and apparatus for automatic software replacement
US5812848A (en) 1995-08-23 1998-09-22 Symantec Corporation Subclassing system for computer that operates with portable-executable (PE) modules
US6161218A (en) 1996-01-16 2000-12-12 Sun Microsystems Inc. Software patch architecture
US5960196A (en) 1996-12-18 1999-09-28 Alcatel Usa Sourcing, L.P. Software release metric reporting system and method
US6253317B1 (en) * 1997-01-09 2001-06-26 Sun Microsystems, Inc. Method and apparatus for providing and handling traps
US6141698A (en) 1997-01-29 2000-10-31 Network Commerce Inc. Method and system for injecting new code into existing application code
US6123737A (en) 1997-05-21 2000-09-26 Symantec Corporation Push deployment of software packages using notification transports
US6075937A (en) 1998-03-18 2000-06-13 International Business Machines Corporation Preprocessing of stored target routines for controlling emulation of incompatible instructions on a target processor and utilizing target processor feedback for controlling non-sequential incompatible instruction emulation
US6298481B1 (en) * 1998-10-30 2001-10-02 Segasoft, Inc. System for modifying the functionality of compiled computer code at run-time

Cited By (85)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8069407B1 (en) * 1998-12-08 2011-11-29 Yodlee.Com, Inc. Method and apparatus for detecting changes in websites and reporting results to web developers for navigation template repair purposes
US6889260B1 (en) * 1999-06-10 2005-05-03 Ec Enabler, Ltd Method and system for transferring information
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
US6981211B1 (en) 1999-09-30 2005-12-27 International Business Machines Corporation Method for processing a document object model (DOM) tree using a tagbean
US6981212B1 (en) 1999-09-30 2005-12-27 International Business Machines Corporation Extensible markup language (XML) server pages having custom document object model (DOM) tags
US6732330B1 (en) 1999-09-30 2004-05-04 International Business Machines Corporation Scripting language blocks to support multiple scripting languages in a single web page
US6718516B1 (en) 1999-09-30 2004-04-06 International Business Machines Corporation Method for verifying context between multiple related XML tags in document object model (DOM)
US7266766B1 (en) 1999-09-30 2007-09-04 International Business Machines Corporation Method for developing a custom tagbean
US6973417B1 (en) 1999-11-05 2005-12-06 Metrowerks Corporation Method and system for simulating execution of a target program in a simulated target system
US6675354B1 (en) 1999-11-18 2004-01-06 International Business Machines Corporation Case-insensitive custom tag recognition and handling
US20040034850A1 (en) * 2000-04-27 2004-02-19 Microsoft Corpaoration Servicing a component-based software product throughout the software product lifecycle
US7310801B2 (en) 2000-04-27 2007-12-18 Microsoft Corporation Servicing a component-based software product throughout the software product lifecycle
US7516441B2 (en) * 2001-06-04 2009-04-07 Microsoft Corporation Method and system for program editing and debugging in a common language runtime environment
US20050034109A1 (en) * 2001-06-04 2005-02-10 Microsoft Corporation Method and system for program editing
US20050268305A1 (en) * 2001-06-07 2005-12-01 Hostetter Mathew J Software atomization
US20030023955A1 (en) * 2001-07-26 2003-01-30 International Business Machines Corporation Efficient monitoring of program variables under debug
US7577942B2 (en) * 2001-07-26 2009-08-18 International Business Machines Corporation Efficient monitoring of program variables under debug
US20060010435A1 (en) * 2001-10-31 2006-01-12 Microsoft Corporation Dynamic software update
US7581217B2 (en) 2001-10-31 2009-08-25 Microsoft Corporation Dynamic software update
US7251812B1 (en) * 2001-10-31 2007-07-31 Microsoft Corporation Dynamic software update
US7117507B2 (en) * 2002-06-03 2006-10-03 Sumisho Computer Systems Corporation Software atomization
US20030225921A1 (en) * 2002-06-03 2003-12-04 Curl Corporation Software atomization
US7281017B2 (en) 2002-06-21 2007-10-09 Sumisho Computer Systems Corporation Views for software atomization
US20030236794A1 (en) * 2002-06-21 2003-12-25 Curl Corporation Views for software atomization
US7747452B1 (en) * 2002-12-31 2010-06-29 Adams Phillip M Enforcement process for correction of hardware and software defects
CN100359485C (en) * 2003-07-10 2008-01-02 华为技术有限公司 Testing device and method for flush-bonding system
US7228527B1 (en) * 2003-07-15 2007-06-05 Hewlett-Packard Development Company, L.P. Method and system for structuring a procedure
US20050141035A1 (en) * 2003-12-04 2005-06-30 Xerox Corporation System and method for processing portions of documents using variable data
US8144360B2 (en) * 2003-12-04 2012-03-27 Xerox Corporation System and method for processing portions of documents using variable data
US20060015708A1 (en) * 2004-07-14 2006-01-19 Boggs Darrell D Microprocessor with branch target determination in decoded microinstruction code sequence
US8024554B2 (en) * 2004-07-27 2011-09-20 Texas Instruments Incorporated Modifying an instruction stream using one or more bits to replace an instruction or to replace an instruction and to subsequently execute the replaced instruction
US20060026403A1 (en) * 2004-07-27 2006-02-02 Texas Instruments Incorporated Compare instruction
US20060265692A1 (en) * 2005-05-20 2006-11-23 Mengjin Su Method, apparatus, and computer program product for code patching
US20080301402A1 (en) * 2007-06-04 2008-12-04 Sangram Alapati Method and System for Stealing Interrupt Vectors
US8145819B2 (en) * 2007-06-04 2012-03-27 International Business Machines Corporation Method and system for stealing interrupt vectors
US20090164982A1 (en) * 2007-12-21 2009-06-25 Sun Microsystems, Inc. Method and system for transforming binaries to use different instructions
US8793662B2 (en) 2008-03-25 2014-07-29 Microsoft Corporation Runtime code hooking for print driver and functionality testing
US9274768B2 (en) 2008-03-25 2016-03-01 Microsoft Technology Licensing, Llc Runtime code hooking for print driver and functionality testing
US20090249368A1 (en) * 2008-03-25 2009-10-01 Microsoft Corporation Runtime Code Hooking
US20110035546A1 (en) * 2008-04-11 2011-02-10 Fujitsu Limited Management device and management method
US9348624B2 (en) 2009-07-23 2016-05-24 International Business Machines Corporation Monitoring file access of java processes
US20120222010A1 (en) * 2009-11-20 2012-08-30 Zte Corporation Loading and Debugging Method and Debugging System Thereof
US9086899B2 (en) * 2009-11-20 2015-07-21 Zte Corporation Loading and debugging method and debugging system thereof
US8745597B2 (en) * 2009-11-25 2014-06-03 International Business Machines Corporation Providing programming support to debuggers
US20110126176A1 (en) * 2009-11-25 2011-05-26 International Business Machines Corporation Providing Programming Support to Debuggers
US20120198424A1 (en) * 2009-11-25 2012-08-02 International Business Machines Corporation Providing Programming Support to Debuggers
US8826244B2 (en) * 2009-11-25 2014-09-02 International Business Machines Corporation Providing programming support to debuggers
US20110214110A1 (en) * 2010-02-26 2011-09-01 Red Hat, Inc. Compiler Mechanism for Handling Conditional Statements
US9134977B2 (en) * 2010-02-26 2015-09-15 Red Hat, Inc. Compiler operation for handling conditional statements
US20110258613A1 (en) * 2010-04-15 2011-10-20 International Business Machines Corporation Software debugger activation based on key performance indicators
US20120265946A1 (en) * 2011-04-12 2012-10-18 Appsense, Limited Bypassing user mode redirection
US8607211B2 (en) 2011-10-03 2013-12-10 International Business Machines Corporation Linking code for an enhanced application binary interface (ABI) with decode time instruction optimization
US8615746B2 (en) 2011-10-03 2013-12-24 International Business Machines Corporation Compiling code for an enhanced application binary interface (ABI) with decode time instruction optimization
US8756591B2 (en) 2011-10-03 2014-06-17 International Business Machines Corporation Generating compiled code that indicates register liveness
GB2509653A (en) * 2011-10-03 2014-07-09 Ibm Linking code for an enhanced application binary interface (abi) with decode time instruction optimization
US8713547B2 (en) 2011-10-03 2014-04-29 International Business Machines Corporation Generating compiled code that indicates register liveness
US8615745B2 (en) 2011-10-03 2013-12-24 International Business Machines Corporation Compiling code for an enhanced application binary interface (ABI) with decode time instruction optimization
WO2013050923A1 (en) * 2011-10-03 2013-04-11 International Business Machines Corporation Linking code for an enhanced application binary interface (abi) with decode time instruction optimization
GB2509653B (en) * 2011-10-03 2015-12-09 Ibm Linking code for an enhanced application binary interface (abi) with decode time instruction optimization
US8612959B2 (en) 2011-10-03 2013-12-17 International Business Machines Corporation Linking code for an enhanced application binary interface (ABI) with decode time instruction optimization
CN103309683A (en) * 2012-03-07 2013-09-18 京信通信系统(中国)有限公司 Software patch embedding method and device for hardware equipment
US9639335B2 (en) * 2013-03-13 2017-05-02 Microsoft Technology Licensing, Llc. Contextual typing
US9696974B2 (en) 2013-03-13 2017-07-04 Microsoft Technology Licensing, Llc. Graph-based model for type systems
US20140282443A1 (en) * 2013-03-13 2014-09-18 Microsoft Corporation Contextual typing
US20140282446A1 (en) * 2013-03-14 2014-09-18 Jeremy Debate Modification of compiled applications and application management using retrievable policies
US9354849B2 (en) * 2013-03-14 2016-05-31 Apperian, Inc. Modification of compiled applications and application management using retrievable policies
US20140289455A1 (en) * 2013-03-25 2014-09-25 Dialog Semiconductor B.V. Memory Patching Circuit
US20150160940A1 (en) * 2013-12-09 2015-06-11 Dspace Digital Signal Processing And Control Engineering Gmbh Method for changing the software in the memory of an electronic control unit
US20150277863A1 (en) * 2014-03-31 2015-10-01 International Business Machines Corporation Selectively controlling use of extended mode features
US20150277869A1 (en) * 2014-03-31 2015-10-01 International Business Machines Corporation Selectively controlling use of extended mode features
US9720661B2 (en) * 2014-03-31 2017-08-01 International Businesss Machines Corporation Selectively controlling use of extended mode features
US9720662B2 (en) * 2014-03-31 2017-08-01 International Business Machines Corporation Selectively controlling use of extended mode features
US11150891B2 (en) * 2014-06-10 2021-10-19 Arm Ip Limited Method and device for updating software executed from non-volatile memory
US9841960B2 (en) * 2015-03-30 2017-12-12 Ca, Inc. Dynamic provision of debuggable program code
US11169791B2 (en) 2015-03-30 2021-11-09 Digital.Ai Software, Inc. Processing, modification, distribution of custom software installation packages
US10698671B2 (en) 2015-03-30 2020-06-30 Arxan Technologies, Inc. Processing, modification, distribution of custom software installation packages
WO2016167797A1 (en) * 2015-04-17 2016-10-20 Hewlett Packard Enterprise Development Lp Morphed instruction according to configuration update
US20180101384A1 (en) * 2015-04-17 2018-04-12 Hewlett Packard Enterprise Development Lp Morphed instruction according to configuration update
US10860763B1 (en) * 2015-09-24 2020-12-08 Cadence Design Systems, Inc. Data routing and multiplexing architecture to support serial links and advanced relocation of emulation models
US11424931B2 (en) 2016-01-27 2022-08-23 Blackberry Limited Trusted execution environment
US10599409B2 (en) 2016-02-02 2020-03-24 Blackberry Limited Application lifecycle operation queueing
US10296447B2 (en) * 2016-12-09 2019-05-21 Fujitsu Limited Automated software program repair
US11301245B2 (en) * 2020-04-24 2022-04-12 International Business Machines Corporation Detecting bias in artificial intelligence software by analysis of source code contributions
CN116737174A (en) * 2023-08-15 2023-09-12 中国兵器装备集团兵器装备研究所 Automatic subsystem generating tool and method based on open source hong Meng system

Also Published As

Publication number Publication date
CA2292123C (en) 2006-08-08
US20030212983A1 (en) 2003-11-13
JP2000181725A (en) 2000-06-30
EP1014263A2 (en) 2000-06-28
EP1014263A3 (en) 2003-06-18
CA2292123A1 (en) 2000-06-14
US6948164B2 (en) 2005-09-20

Similar Documents

Publication Publication Date Title
US6948164B2 (en) Method and system for modifying executable code to add additional functionality
US5170465A (en) Incremental-scanning compiler for source-code development system
US5325531A (en) Compiler using clean lines table with entries indicating unchanged text lines for incrementally compiling only changed source text lines
US5313387A (en) Re-execution of edit-compile-run cycles for changed lines of source code, with storage of associated data in buffers
US5182806A (en) Incremental compiler for source-code development system
US5193191A (en) Incremental linking in source-code development system
US5201050A (en) Line-skip compiler for source-code development system
US5761510A (en) Method for error identification in a program interface
US6067641A (en) Demand-based generation of symbolic information
US7263689B1 (en) Application program interface for dynamic instrumentation of a heterogeneous program in a distributed environment
Linton The Evolution of Dbx.
US20040205720A1 (en) Augmenting debuggers
WO1997043711A1 (en) Incremental byte code compilation system
US8448152B2 (en) High-level language, architecture-independent probe program compiler
AU1956897A (en) Interactive software development system
US5680584A (en) Simulator system for code execution and debugging within a multi-architecture environment
US5301327A (en) Virtual memory management for source-code development system
AU638999B2 (en) Incremental compiler for source-code development system
CN111400256A (en) Method and device for calling resource file by application program
Lyu et al. A procedure-based dynamic software update
CN112882701A (en) Executable file static pile inserting technical framework supporting multiple architectures
JPH11110256A (en) Device and method for debugging program, and computer readable recording medium recorded with the method for the same
CN117234953B (en) Kernel debugging method based on shadow code cache
US20240012624A1 (en) Non-transitory computer-readable storage medium with executable development program stored thereon, information processing system, information processing apparatus, and information processing method
Altman et al. DAISY dynamic binary translation software

Legal Events

Date Code Title Description
AS Assignment

Owner name: APPLIED MICROSYSTEMS CORPORATION, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:TINKER, JEFFREY L.;REEL/FRAME:009669/0007

Effective date: 19981207

AS Assignment

Owner name: METROWERKS CORPORATION, TEXAS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:APPLIED MICROSYSTEMS CORPORATION;REEL/FRAME:013609/0388

Effective date: 20021101

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: APPLE INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ZENITH INVESTMENTS, LLC;REEL/FRAME:034749/0791

Effective date: 20141219