Embedded program flow information for object code manipulation

Abstract: A method and apparatus for making flow information available for object code manipulation tasks are disclosed. Flow information is generated and saved either by a compiler or by a flow information generator. A compiler generates the flow information directly from a source file while the compiler is compiling the source file into an executable file. A flow information generator generates the flow information from an executable file in a manner similar to a compiler. Further, the flow information generator groups the executable file into units of text and traces the units to produce the flow information. The binary information thus retrieved is saved and embedded either in a text or a header of the executable file or placed in a file separate from the executable file. The flow information may be used in object code manipulations including binary translations, binary-to-binary optimizations, program tracing, and program debugging.

Description: The invention relates to the field of program flow information. More particularly, the invention relates to a method and apparatus for using embedded program flow information for binary manipulation. Tasks involving binary manipulations include binary translation which is the process of converting binary code targeted for one machine to another machine, and binary optimization which is the process of converting a less efficient binary code to a more efficient binary code. Such tasks are difficult due to the need to generate flow information for the executable file upon which the particular binary manipulation is being performed. Flow information is information describing the flow of program execution sequences. Flow information includes but is not limited to: control flow information, (such as basic block, superblock, tree, and/or hyperblock successors and predecessors), data flow information (such as register liveness or information concerning assignment of variables to registers), data type information, and information about array access patterns, alias information indicating which memory access might be altered as a side effect of some instruction or instruction sequence, identification of idiomatic control structures such as jump tables, and identification of idiomatic data flow information such as stride lengths for array accesses. Typically, flow information is derived each time the need arises during a binary manipulation. The drawback in having to derive flow information as the need arises is the amount of time consumed in building such information during a binary manipulation. Problems may be encountered during a binary manipulation if certain necessary flow information is not available. For example, a problem arises during a binary translation if a program being translated has jump tables. To perform an accurate binary translation of a program, the entire flow of the region of interest must be known. A jump instruction in a program being translated may indicate a jump to one of a given number of different locations depending upon a value stored at a register X. If the value of the register X is not known, the binary translation being performed will not produce accurate results. If a program can be divided into semi-independent sub-units such as modules or procedures, it suffices to know the entire flow of only the sub-unit being manipulated. The efficiency of a binary-to-binary optimization depends on the level of the detail of the flow information. Thus to turn poor code into good code or good code into better code, more accurate flow information is desirable. Finally, in program debugging, bug fixing, and tracing activities, certain embedded flow information is desirable to perform such tasks in a more efficient manner. A progam being debugged must be traced step by step. For example, in a program being debugged, if a register Y is assigned a value, and the flow information indicates that the value assigned to register Y never gets used in the rest of the program, this detects a potential bug in the program. With the advent of increased interest in certain tasks involving binary manipulations and given that the generation of flow information is time consuming, there is a need for a method and apparatus to make necessary flow information available during tasks involving binary manipulations. Compcon Spring '89 - 34th IEEE Computer Society International Conference - Intellectual Leverage, 27 February 1989 - 3 March 1989, San Francisco, CA, US, pages 282-287, XP000124692 Banning J: 'The XDOS Binary Code Conversion System' describes an XDOS binary code conversion system, which takes the binary images of programs that were written to run on an IBM PC and converts them into programs that will run on a number of different computers that use the UNIX ® operating system. The paper discusses the use of automatic and human aided-conversion techniques, the techniques used to analyze programs, optimizations that are performed during conversion, run-time strategies, and the relative performance of converted code. The XDOS conversion system has three parts. The first part is the XDOS analyzer, an interactive program that analyzes a PC application program under the guidance of a human analyst. The analyzer reads in a binary application program, tries to analyze it, and informs the human analyst about parts that it cannot analyze. The human analyst tells the analyzer how to overcome these problems via commands in an application-specific data file. This process continues iteratively until the program is completely analyzed. Once this is done, the analyzer creates a key file that contains a summary of all the analysis information and directions for conversion of the application program. The second part of the XDOS system, called the converter, takes this key file and uses the information in it to automatically convert the application program into a program for a particular computer architecture. Due to the nature of the information in the key file, this conversion is quite fast. There is actually a version of the converter for each target processor architecture (but not for each version of UNIX running on that architecture). The key file, however, is independent of the target architecture as it contains only application-specific analysis information. The third part is a run-time library that is linked with the output of the converter to form a UNIX program. It is the run-time library that maps DOS calls, PC ROM BIOS calls, and accesses to PC hardware locations into UNIX system calls. The run-time library is the only portion of XDOS that is specific to a particular version of UNIX (eg., AT & T System V versus BSD 4.2), is written in a high level language, and can be ported relatively easily. According to a first aspect of the present invention there is provided a method wherein program flow information for an executable program is generated, and said program flow information is saved in a memory for use after a program compilation, characterised in that the program flow information is generated in the form of binary code for an executable program during compilation of a source program into said executable program or subsequent to a program compilation, and said program flow information being approximately for the entire executable program; and said program flow information is saved in one of said executable program and a file separate from said executable program; portions of executable code of said executable program are referenced to corresponding program flow information; and said program flow information is used for binary manipulation including at least one of binary translation, binary-to-binary optimization, program tracing and program debugging. According to a second aspect of the present invention there is provided an apparatus comprising a flow information generator configured to generate program flow information and a flow information saving element configured to save said program flow information generated by said flow information generator for use after a program compilation characterised in that said flow information generator is configured to generate program flow information in the form of binary code for an executable program during compilation of a source program into said executable program or subsequent to a program compilation, said program flow information being approximately for the entire executable program; said apparatus further comprising a unit separator element configured to separate one of said executable program and said source program into units such as basic blocks; a unit tracer element configured to trace one of said units of said executable program and said source program to generate said flow information; a referencing element configured to reference each of said units of said executable program to corresponding flow information; and wherein said program flow information is saved in one of said executable program and a file separate from said executable program, and used for binary manipulation including at least one of binary translation, binary-to-binary optimization, program tracing and program debugging. In the present invention, flow information is generated and saved by either the compiler or by an embedded flow information generator (EFI generator). In the first method, the compiler generates the flow information directly from a source file. In the latter method, the EFI generator generates the flow information from an executable file in a manner similar to a compiler. The flow information thus retrieved may be embedded in the text of the code of the executable file, embedded in the symbol table of the header of the executable file or placed in an entirely separate file. The flow information may be used for tasks involving certain binary manipulations including such tasks as binary translations and binary-to-binary optimizations. A binary translation converts the format of a program which runs on one machine so that it may run on another machine. A binary-to-binary optimization involves making an executable program faster, adding new instructions, and/or making the binary program shorter to save memory space. These and other tasks involving binary manipulations require certain flow information for such tasks to run in an efficient manner. In sum, the availability of pre-generated flow information for an executable program provides fantastic efficiency in the performance of tasks involving binary manipulations on such an executable program. Further, tasks involving binary manipulations become faster and more efficient as compared to the past methods involving the generation of flow information on a need basis during binary manipulations. By way of example only, a specific embodiment of the present invention will now be described, with reference to the accompanying drawings, in which:- Figure 1 is a block diagram illustrating a flow information generator of the present invention. Figure 2 is a flow chart illustrating an embedded flow information file generation by a compiler. Figure 3 is a flow chart illustrating an embedded flow information file generation by an embedded flow information generator. Figure 4 illustrates an exemplary flow information file keyed to basic blocks in a binary code. Figure 5 illustrates an exemplary binary code with embedded flow information. Figure 6a illustrates an exemplary binary code. Figure 6b illustrates the same exemplary binary code with EFI. Figure 7 illustrates an exemplary program header augmented to include flow information. Figure 8 illustrates an exemplary program header augmented to include flow information. Figure 9 illustrates a binary-to-binary optimization performed without the embedded flow information of the present invention. Figure 10 illustrates a binary-to-binary optimization using pre-generated embedded flow information of the present invention. Figure 11a illustrates an exemplary binary code. Figure 11b illustrates the same binary code after a binary-to-binary optimization. Apparatus and method for providing embedded flow information for use in binary manipulations is disclosed. For purposes of explanation, specific exemplary modules, instructions, etc., are set forth to provide a thorough understanding of the present invention. However, the invention may be practiced without the specific details described herein. Flow information for an executable file might be generated multiple times by a compiler from a source code during a compilation process. Once the compilation process is completed, some of the flow information that is discarded during compilation can never be accurately retrieved again. Figure 1 is a block diagram illustrating a flow information generator of the present invention. CPU 32 of computer 30 drives flow information generator 38 of memory 34. Flow information generator 38 generates program flow information for source code or executable code 36 and flow information saving element 40 saves flow information 42 generated by flow information generator 38. Flow information generator 38 may either be source program based or executable program based. A source program based flow information generator generates program flow information directly from a source code of an executable program while an executable program based flow information generator generates program flow information from executable code and hence after program compilation. Program flow information generated directly from the source code is generated more quickly and is more accurate than program flow information generated from an executable code. Flow information generator 38 includes unit separator element 44, unit tracer element 46 and referencing element 48. Unit separator element 44 separates code 36 into units such as basic blocks and unit tracer element 46 traces the units to generate flow information 42. Units of an executable program are referenced to corresponding flow information by referencing element 48. Once flow information generator 38 generates flow information for code 36, flow information saving element 40 saves the flow information generated from code 36 as flow information 42. The flow information may be saved by being embedded into a program header by embedded program header saving element 54, saved as an embedded file by embedded file saving element 56 or saved as embedded in a program text by embedded program text saving element 58. Figure 2 illustrates the present invention's method of saving the flow information generated by the compiler for use after the compilation process. In step 110, flow information is generated during compilation of a source file. In step 120, as the flow information is generated, the compiler saves the flow information in a file separate from the executable file, or either in the header or in the text of the executable file. In step 130, the compiler generates the executable file. Finally, in step 140, the flow information generated and saved during compilation may be used during binary manipulations after the compilation process. Figure 3 illustrates an alternative method of generating and saving flow information. In steps 200 and 210, an embedded flow information (EFI) generator generates flow information from an executable file in a manner similar to a compiler generating flow information from a source file. The EFI generator examines an executable file and divides the executable file into units such as basic blocks, builds an array of the units and steps through those units to generate the flow information. This method derives the flow information from an executable file whereas in the above described compilation method, the compiler generates the flow information directly from a source file. In step 220, the EFI generator saves the flow information in a file separate from the executable file, or in either the header or the text of the executable file. Finally, in step 230, the saved flow information may be used in a binary manipulation. Several methods exist for implementing EFI. Three such methods will be described in the following description. Figure 4 illustrates a method of implementing EFI in a separate file foo.fi 300 with each of its flow information blocks 310 to 360 keyed to corresponding basic blocks (BB) 370 to 420 of an executable file, foo.exe 430. Alternatively, flow information may be keyed to any number of different ways for representing parts of an executable file such as to superblocks, hyperblocks, trees, arcs between basic blocks, arcs between superblocks, arcs between hyperblocks, arcs between trees and individual statements. Figure 5 illustrates the method of implementing EFI as embedded in the code of the executable file. An executable file foo.exe 500 is separated into five basic blocks BB1 through BB5 510 to 550. Each basic block in the executable file foo.exe 500 contains flow information EFI 560, either as non-executable code or as data to be branched around. As an alternative, EFI 560 may be keyed to superblocks, arcs between basic blocks, arcs between hyperblocks, individual statements, etc., instead of keyed to the basic blocks as illustrated in Figure 4. Figure 6a illustrates an exemplary binary code. Figure 6b illustrates the same exemplary binary code with EFI. The exemplary binary code in Figure 6a consists of program header 10 containing load information (i.e. information on how to load the program in memory), and text segment 11 containing executable code (in which data may or may not be embedded) and data segment 12. In the binary code of Figure 6a, the contents of a variable debug are placed into register 1 (reg 1 ) and a branch conditionally causes a jump to a program exit routine if the content of register 1 is equal to zero. Otherwise, register 1 is loaded with a pointer to the message "debugging on". Finally, the program calls a subroutine (printf) to print the message. The same binary code of figure 6a with EFI may be, for example, in the form of the binary code illustrated in Figure 6b. Each basic block is preceded by an identifying marker .text bb (bb standing for basic block) and a basic block number, a list of predecessor blocks and a list of registers live on entry to the block. Appended at the end of each basic block is information concerning registers containing live data at block exit, and a list of successor blocks. Second basic block bb1, for example, is preceded by basic block bb0 and followed by basic block bb14. Further, information is not passed to basic block bb1, (.live-in none), but bb 1 passes information to its successor through register 1 (.liveout reg 1 ). Alternatives to the basic scheme introduced by the binary code of Figure 6b with EFI may include implicitly numbering the basic blocks according to the basic blocks' order in the program and discarding the ".text bb number" identifier at the beginning of each basic block. In the alternative, the basic blocks may be implicitly numbered according to the basic blocks' location in memory. In addition, the binary code may be grouped into units of superblocks, hyperblocks, decision trees, etc., instead of grouping the binary code into units of basic blocks. Information regarding whether a register is assigned a value may be extended to include information on variables in memory as well. Finally, instead of attaching the EFI to each node (control flow graph), the very same embedded flow information may be attached to the arcs between the nodes (control dependence graph). Further, relocation information is generally present in the object files during link time and currently discarded after the linker has done its job. This information may be retained in the final binary file as an example of other types of information that may be contained in the embedded flow information. Other optimizations and extensions to the type of information that may be included as EFI includes basic data flow information for scalar variables and registers, basic data flow information for expressions and constants, interprocedural information for registers and scalar variables, alias information for scalar variables, and data dependence information. Further, basic information, interprocedural information, and alias information for arrays may also be included as EFI. In addition, alias information indicating which memory access might be altered as a side effect of some instruction or instruction sequence, and/or identification of idiomatic control structures such as jump tables, identification of idiomatic data flow information such as stride lengths for array accesses may be included as EFI. Figure 7 illustrates another method for implementing EFI. Binary code foo.exe 600 contains program header 610 and executable code 620. For each basic block BBnumber in executable code 620, program header 610 retains appropriate flow information FI BBnumber . As an alternative, flow information FI BBnumber may be keyed to blocks of executable code 620 which may be in units of superblocks, arcs between basic blocks, arcs between hyperblocks, individual statements, etc. Figure 8 illustrates an exemplary embodiment of a standard UNIX® a.out format augmented to include embedded flow information. This exemplary embodiment includes flow information 20 in the existing symbol table segment of header 21. EFI in the symbol table contains text segment information t0, t1, t2, t14 and data segment information D0. Each text segment information contains the EFI for each basic block of the program text. For example, t1 is the EFI for the basic block 1 of the program text and gives the program text location information and the information regarding the predecessor basic block which in this case is basic block 0 as indicated by "predecessor t0". In addition, the EFI in t1 includes information on whether or not there is live data coming into the basic block 1 which in this case is none as indicated by "livein none", and whether there is any live information going out of basic block 1. In this case register 1 contains data as indicated by "liveout reg 1 ". Finally, the EFI in t1 includes information on the successor block which in this case is basic block 14 as indicated by "successor t14". Figure 9 illustrates the use of EFI for binary-to-binary optimization. In a binary-to-binary optimization, an executable program is modified such that it runs faster, or utilizes new instructions or utilizes less memory space. Without the availability of a pre-generated EFI of the invention, a binary-to-binary optimizer 710 generates its own flow information 720 from executable program foo.exe 700 to produce a better executable program foo.exe 730. The flow information is generated by the optimizer during the optimization process requiring extra time and memory for the optimization to take place. In Figure 10 in contrast, the EFI of the executable program foo.exe 700 is provided in EFI file foo.fi 760. The binary-to-binary optimizer uses the EFI in file foo.fi 760 to optimize executable program foo.exe 700 to generate an optimized executable program foo.exe 780. A simple example of how pre-generated EFI is used during binary-to-binary optimization is illustrated by examining the EFI in Figure 11a. In a case in which an instruction set architecture was being optimized to contain a move-conditional instruction, abbreviated as movcc, a movcc instruction "move-if-cc reg a to reg b " conditionally copies information from a register a to a register b depending upon some condition cc contained within a condition code register. As an example, "move-if-equals reg 1 to reg 2 " copies the contents of register 1 to register 2 if and only if the condition contained within the condition code register indicates an equal. Figures 11a and 11b correspond to an algorithm for setting a register 3 equal to one if the content of register 1 equals that of register 2. In Figure 11a, three basic blocks exist. In basic block t1 register 1 is compared with register 2 and if the contents of register 1 and register 2 are not equal, the program branches to basic block t3 and the program continues. Otherwise if register 1 and register 2 contain equal values, there is no branching to t3; instead basic block t2 is entered and register 3 is set to equal the constant one. By optimizing an executable program by adding a move-conditional instruction as described previously, Figure 11a is transformed into a more simple code sequence as illustrated in Figure 11b. In Figure 11b, there are only two basic blocks, namely basic block t1 and basic block t3. In basic block t1, register 1 is set to a constant value of one and register 1 and register 2 are compared. If register 1 and register 2 are not equal, the contents of register 4 is copied to register 3. Otherwise, basic block t3 is entered and the program continues. For the transformation from the code in Figure 11a to the optimized code in Figure 11b to occur, register 4 must be available and not assigned any value on exit from basic block t1 (i.e. reg 4 ∉ liveout (t1)). In addition, basic block t2 must not have any predecessors other than basic block t1 which may interfere with the optimization (i.e. pred(t2) == {t1}). The two required pieces of information are easily retrieved out from the pre-generated EFI of the program. Although such information may be derived in the absence of EFI, such generation of information would require processing a large amount of code. Pre-generated EFI allows optimization without the need for processing the entire code. Instead, sections of pre-generated flow information may be examined as a much simpler "peephole" to process, without regard to the surrounding code. Other uses for EFI include use of EFI in binary translations. In a binary translation, a binary code targeted for one type of machine is converted by a binary trarslator into a binary code targeted to a different type of machine. For example, a binary translator may convert a PC program into a program that runs on a work station. Without the EFI of the present invention, a binary translator must generate its own flow information, requiring extra time and memory. Given the use of the pre-generated flow information of the present invention, the binary translator does not have to gererate any flow information as it translates the executable code. In addition, the binary translator will only have to examine pertinent portions of the EFI used by the binary translator and may ignore the rest of the EFI. Hence, a binary translator is able to process the translation faster. Another example of the use of EFI of the present invention is in program tracing, debugging and bug fixing. Program tracing is a process of running an annotated binary code in order to derive a program execution profile. Debugging is the process of identifying incorrect code within a binary file. Bug fixing is the process of substituting correct code for incorrect code. With the use and availability of EFI, a debugger may produce a greatly improved level of information regarding a particular program the debugger is tracing or debugging. Information which may be used during program tracing, debugging or bug fixing includes where and if a certain variable is used in a program. For example, if in a program, a given register X is assigned a value and if the value in register X is never used in the rest of the code, the fact that the value is never used may be an indication that there is an error in the program being debugged. In sum, EFI greatly improves the efficiency as well as the type of information a debugger produces regarding a program it is debugging. There are many advantages to embedding flow information in the executable code itself rather than leaving it in a separate file. One of the advantages is that the executable code cannot easily be separated from the EFI. Another advantage is that the EFI does not overload the file system with extra files that have to be maintained. Yet another advantage is that the EFI can be positioned near the code to which it refers for easier manipulation. What has been described is a method and apparatus for including flow information in the final, released form of computer software. Such flow information may be embedded in-line with binary code, included in the program header or any other similar existing structure within the program itself, or included as a separate file associated with, but separate from, the binary code itself. The type of information which may be included in EFI includes, but is not limited to, control flow information, such as basic block, superblock, tree, and/or hyperblock successors and predecessors. In addition, data flow information, such as register liveness or liveness of local and global variables, data type information, and information about arrays and array access patterns may also be included as EFI. Further, alias information indicating which memory access may be altered as a side effect of some instruction or instruction sequence, identification of idiomatic control structures such as jump tables, and identification of idiomatic data flow information such as stride lengths for array accesses may also be included as EFI. Finally, the pre-generated flow information is useful for many different types of binary manipulations such as binary translations, binary-to-binary optimizations, program tracing, debugging and bug fixing. The use of pre-generated flow information for binary transformation produces a more efficient, memory saving and faster method of performing various binary transformations as compared to the method of building flow information entirely from scratch each time a binary transformation/manipulation is performed. While certain exemplary embodiments have been described in detail and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad invention, and that this invention is not to be limited to the specific arrangements and constructions shown and described, since various other modifications may occur to those with ordinary skill in the art.

Claims: A method wherein program flow information for an executable program is generated, and said program flow information is saved in a memory for use after a program compilation, characterised in that the program flow information is generated (110) in the form of binary code for an executable program during compilation of a source program into said executable program or subsequent to a program compilation, and said program flow information being approximately for the entire executable program; and said program flow information is saved in one of said executable program and a file separate from said executable program; portions of executable code of said executable program are referenced to corresponding program flow information; and said program flow information is used (140) for binary manipulation including at least one of binary translation, binary-to-binary optimization, program tracing and program debugging. The method of claim 1 further comprising the steps of: grouping said source program into units of text; and tracing said units of text to retrieve said program flow information. The method of claim 1 further comprising the step (120) of saving said program flow information in a program header of said executable program. The method of claim 1 further comprising the step (120) of saving said program flow information in the text of said executable program. The method of claim 1 further comprising the steps of: grouping said executable program into units of text; and tracing said units of text to retrieve said program flow information. An apparatus comprising a flow information generator (38) configured to generate program flow information and a flow information saving element (40) configured to save said program flow information generated by said flow information generator (38) for use after a program compilation characterised in that said flow information generator (38) is configured to generate program flow information in the form of binary code (36)for an executable program during compilation of a source program into said executable program or subsequent to a program compilation, said program flow information being approximately for the entire executable program; said apparatus further comprising a unit separator element (44) configured to separate one of said executable program and said source program into units such as basic blocks; a unit tracer element (46) configured to trace one of said units of said executable program and said source program to generate said flow information; a referencing element (48) configured to reference each of said units of said executable program to corresponding flow information; and wherein said program flow information is saved in one of said executable program (36) and a file (42) separate from said executable program, and used for binary manipulation including at least one of binary translation, binary-to-binary optimization, program tracing and program debugging. The apparatus of claim 6 further comprising: a CPU (32) for driving said flow information generator (38); and a memory (34) for saving said program flow information. The apparatus of claim 6 wherein said flow information saving element (40) further comprises an embedded program header saving element (54) configured to save said flow information in a program header of said executable program. The apparatus of claim 6 wherein said flow information saving element (40) further comprises an embedded program text saving element (58) configured to save said flow information in a program text of said executable program. A system for generating flow information for use after program compilation, including code configured for storage on a computer-readable apparatus and executable by a computer, the code including a plurality of modules each configured to carry out at least one function to be executed by the computer, the system comprising apparatus according to any one of claims 6 to 9.

Inventors: RICHARDSON STEPHEN E, RICHARDSON, STEPHEN E.
Applicants: SUN MICROSYSTEMS INC, SUN MICROSYSTEMS, INC.
Application year: 1995
Main classification: G06F9
IPC codes: G06F9, G06F11