When software developers discover a problem in a computer program (such as an operating system kernel), they typically create a patch to fix the problem. A patch is an arbitrary source code modification to the computer program, and it can result in changes to many functions within the computer program. Automatically determining what computer program functions are changed by an arbitrary source code modification can be useful for many software processes, such as determining how to “hot update” a computer program (i.e., apply a source code modification to a running program without restarting the program).
Determining which computer program functions are changed by a source code modification is an important task that a hot update system must accomplish. Prior hot update systems determined which functions changed as a result of a source code modification at the source code layer, and thus were subject to a number of limitations (for example, they do not handle function inlining or implicit casting correctly).
The present invention is an improved method for determining which functions within a computer program are changed as a result of a source code modification.
Determining which functions within a computer program are changed as a result of a source code modification can be challenging in many cases. Consider a source code modification that changes a data type in a function prototype in a C header file (e.g., from an “int” to a “long long”). Because of implicit casting, this patch implies changes to the executable code of any functions that call the prototyped function. Any method that attempts to determine which functions are changed by this patch by looking only at source code, not at object code, will encounter the problem that the callers of the prototyped function have not had their source code modified at all, even after C preprocessing.
The present invention can identify which functions are changed by an arbitrary source code modification, while avoiding detecting extraneous differences. The present invention does not require any information about programming language semantics, such as information about the semantics of implicit casting in C.
The present invention will become more fully understood from the detailed description given below and the accompanying drawing, which are given by way of illustration only and thus are not limitative of the present invention, wherein:
As used herein, the term “computer program” or “program” refers to any computer program, including an operating system kernel.
The present invention determines which functions are changed by a source code patch while operating entirely at the object code layer—in other words, by looking at compiler output rather than the source-level contents of the patch.
The present invention must deal with the complication that compiler output can obscure the desired changes by introducing extraneous differences. Without taking any special measures, the object code corresponding to before and after the source code modification will contain many extraneous differences. These extraneous differences are not the result of semantic changes (i.e., changes that adjust the meaning of the code) introduced by the source code modification. For example, a number of extraneous differences result from location assumptions inherent in object code, e.g., the offsets provided to immediate jump instructions that are calculated relative to the program counter. The present invention makes it possible to generate a list of functions that are changed by an arbitrary source code modification, gaining the benefit of working at the object code layer while avoiding extraneous differences.
In order to avoid extraneous differences, the present invention employs compiler modifications and a specially-designed comparison process. Specifically, the compiler is modified to ensure that it generates relocations for all references to functions and data structures, which results in more general code that does not make assumptions about where other functions and data structures are located in memory. This compiler behavior can be accomplished using many different techniques, such as the “ffunction-sections” and “fdata-sections” configuration controls for the GNU C compiler.
As used below, the term “pre object code” refers to the output of compiling the computer program's original source code using the modified compiler. As used below, the term “post object code” refers to the output of compiling the computer program's modified source code using the modified compiler.
In order to determine which functions were changed by the source code patch, the present invention compares the object files by comparing corresponding object code sections between the pre object code and the post object code.
If a function has not changed, the non-relocation contents of the pre object code and the post object code will be identical, and all of the relocations will be equivalent. Two relocations are equivalent if they refer to program functions that have the same name, or refer to program data objects that have the same contents.
In order to determine which functions are changed by a source code patch to a computer program, the present invention performs the following process.
First, the present invention compiles the computer program's original source code, using a compiler modified or configured to generate, in compiler output, a relocation entry for each program access to a function or data item. The result of this compilation is the pre object code.
Second, the present invention compiles the computer program's source code, modified by applying the source code patch, using a compiler modified or configured to generate, in compiler output, a relocation entry for each program access to a function or data item. The result of this compilation is the post object code.
Using the results of the previous two steps, the present invention constructs a list of object code differences by comparing the pre object code with the post object code, excluding any object code differences where the pre object code and post object code both contain relocations that are equivalent.
The object code differences resulting from this process provide a list of the functions that have changed as a result of the source code modification.
Thus, the improved method of the present invention can be summarized as follows:
step (a) 210—compiling said computer program's source code, using a compiler modified or configured to generate, in compiler output, a relocation entry for each program access to a program function or a program data item; and
step (b) 220—compiling source code resulting from modifying said computer program's source code with said source code modification, using a compiler modified or configured to generate, in compiler output, a relocation entry for each program access to a program function or a program data item; and
step (c) 230—constructing a list of object code differences by comparing the object code produced from step (a) versus the object code produced from step (b), and excluding from the list any object code difference for which:
The invention being thus described, it will be obvious that the same may be varied in many ways. Such variations are not to be regarded as a departure from the spirit and scope of the invention. Rather, the scope of the invention shall be defined as set forth in the following claims and their legal equivalents. All such modifications as would be obvious to one skilled in the art are intended to be included within the scope of the following claims.
Number | Name | Date | Kind |
---|---|---|---|
5119495 | King | Jun 1992 | A |
5215794 | Johnson | Jun 1993 | A |
5504901 | Peterson | Apr 1996 | A |
5848274 | Hamby et al. | Dec 1998 | A |
5930507 | Nakahira et al. | Jul 1999 | A |
6145124 | Price | Nov 2000 | A |
6317873 | Townsend | Nov 2001 | B1 |
6446257 | Pradhan et al. | Sep 2002 | B1 |
6625807 | Chen | Sep 2003 | B1 |
6625808 | Tarditi | Sep 2003 | B1 |
6658421 | Seshadri | Dec 2003 | B1 |
6687899 | Shann | Feb 2004 | B1 |
6766514 | Moore | Jul 2004 | B1 |
6901584 | Shann | May 2005 | B2 |
6928536 | Duesterwald | Aug 2005 | B2 |
7299462 | Shann et al. | Nov 2007 | B2 |
7412697 | Moore et al. | Aug 2008 | B2 |
7549147 | Futoransky et al. | Jun 2009 | B2 |
7620943 | Garthwaite | Nov 2009 | B1 |
7752609 | Rioux | Jul 2010 | B2 |
7779394 | Homing et al. | Aug 2010 | B2 |
7814467 | Li et al. | Oct 2010 | B2 |
7873952 | Shtilman et al. | Jan 2011 | B2 |
7886287 | Davda | Feb 2011 | B1 |
8181167 | Zhao | May 2012 | B2 |
8245203 | Becker | Aug 2012 | B2 |
8245209 | Gupta | Aug 2012 | B2 |
8276129 | Kiel et al. | Sep 2012 | B1 |
8448152 | Moore et al. | May 2013 | B2 |
20040054569 | Pombo et al. | Mar 2004 | A1 |
20040107416 | Buban | Jun 2004 | A1 |
Entry |
---|
Maoz et al, “A compiler for multimodel scenarios: Transforming LSCs into AspectJ”, ACM Trans. on Software Eng. and Methodology, vol. 20, No. 4, article 18, pp. 1-41, 2011. |
Titzer et al, “Improving compiler runtime separation with XIR”, ACM VEE, pp. 39-49, 2010. |
Kotha et al, “Automatic parallelization in a binary rewriter”, IEEE, pp. 547-557, 2010. |
Sutter et al, “Link time binary rewriting techniques for program compaction”, ACM Trans. on Prog. Lang. and Sys. vol. 27, No. 5, pp. 882-945, 2005. |
G. Altekar et al. “OPUS: Online Patches and Updates for Security”, Proc. of the 14th USENIX Security Symposium, 2005, USENIX Assoc., Berkeley, CA, 16 pages. |
A. Baumann et al., “Reboots are for Hardware: Challenges and Solutions to Updating an Operating System on the Fly”, Jun. 2007, USENIX Assoc., 14 pages. |
A. Baumann et al., “Providing Dynamic Update in an Operating System”, Apr. 2005, Proc. of the USENIX Annual Technical Conference, USENIX Assoc., 13 pages. |
B. Buck et al, “An API for Runtime Code Patching”, J. of High-Performance Computing Applications, Jan. 2000, Sage Publications, Inc., 12 pages. |
H. Chen et al., “Live Updating Operating Systems using Virtualization”, Proc. of the 2nd ACM Conference on Virtual Execution Environments, Jun. 14-16, 2006, 10 pages. |
K. Makris et al., “Dynamic and Adaptive Updates of Non-Quiescent Subsystems in Commodity Operating System Kernels”, Proceedings of the 2nd ACM EuroSys. Conference, Mar. 21-23, 2007, 14 pages. |
I. Neamtiu et al., “Practical Dynamic Software Updating for C”, Proceedings of the 2006 ACM Conference on Programming Language Design and Implementation, Jun. 11-14, 2006, 12 pages. |
A. Tamches et al., “Fine-Grained Dynamic Instrumentation of Commodity Operating System Kernels”, Proceedings of the 3rd OSDI Symposium, Jan. 1999, 14 pages. |
Number | Date | Country | |
---|---|---|---|
20100269105 A1 | Oct 2010 | US |