JP5128602B2 - Method and apparatus for making dynamically linked function calls for program code conversion - Google Patents

Description

  The present invention relates generally to the field of computers, and more particularly to a program code conversion method and apparatus useful in code converters, emulators, and accelerators that perform program code conversion including, for example, dynamically linked function calls. About.

Over the embedded and non-embedded CPU markets, leading instruction set architectures (ISAs) are known, for which there are numerous software programs that can be “accelerated” with respect to performance. "Transformed" into a myriad of advanced processors that are possible or can provide even better cost / performance benefits if the processor can transparently access its associated software. (Translated) . It is also known that there is a powerful CPU architecture that is fixed to the ISA and cannot be evolved in terms of performance or market scope, but will benefit from the “synthetic CPU” common architecture. It has been.

In most cases, the program code described for a first type of computer processor ( also referred to as a “subject” processor , also referred to as a target processor) is executed on a second type of processor ( also referred to as a “target” processor , also referred to as a target processor ). desirable. In this case, the subject program can be executed on the target processor by executing the program code conversion using an emulator or a translator . International Publication No. WO 00/22521 discloses a program code conversion method and apparatus that facilitates acceleration, conversion, and common architecture functions as may be used in embodiments of the present invention.

  The subject program to be converted usually comprises a large number of units of subject code, which includes a subject application and a large number of subject libraries, some of which may be proprietary. Some of which are provided as part of the subject OS ("system library"). When the subject program is executed, a path of control flow between these different units of subject code as function calls is formed to the library.

For example, Sun Microsystems Inc. On certain operating systems, such as Solaris (Solaris) , the process of linking a function call to the library code that executes the function can be performed at runtime, and this procedure is dynamic Known as a link. Dynamic linking is performed by dynamic linker code and involves the use of an intermediate control structure known as a procedure linkage table (PLT).

A PLT is an integral part of a compiled program and has inputs that contain link information for each of the library functions required for that program. In standard execution of a program, when the first call to a library function occurs, control flow jumps to the PLT input associated with that function. The PLT input for the function controls the stage linking process by including dynamic linker code. The dynamic linker code causes the link information for the function to be updated. By updating the link information, the dynamic linker code forms a link from the PLT input for the function to the library code that executes the function. The link constructed in this way lasts until the end of program execution.

As a result, the dynamic linker code can pass the control flow of code in the library so that the function is executed.
Subsequent calls to the function by the program pass control flow as it was done for the PLT input in advance. Since the PLT input has been updated with a link to the library code that performs the function, in these subsequent calls, the PLT passes control flow directly from the PLT to the library. These subsequent calls do not require further updates of the PLT input or further calls of the dynamic linker.

In a particular operating system, performing link formation between a PLT input for a function and a library containing code to execute the function rewrites data associated with the PLT, such as a global offset table Has an effect. As a result, the global offset Deburu was rewritten et al., It is possible to read at runtime by the code in the PLT input, to allow the formation of a link. In certain other operating systems, such as Solaris, for example, performing a link formation between a PLT input for a particular function and a library containing that function results in executable code that forms the PLT input itself. Has another effect of rewriting .

Use of PLT as intermediate control structure as described above, in particular, by rewriting the code comprising a PLT in a first time the function is called, rewriting the link information in the PLT, as an integral part in the dynamic link method Complicates program code conversion for subject code using PLT.

Rewriting et a subject code (also referred to as target code), there is a possibility that correspond to previously translated target code (also referred to as object code), the code rewriting in runtime problem for dynamic translator Pose. If such rewriting subject code occurs, all target code conversion of the subject code rewriting it was is identified, and must be discarded as obsolete. Therefore, translator, all target code sequence corresponding to a particular subject code addresses are rewritten et al (i.e., conversion) must be able to identify.

In a dynamic translator , it is difficult and sometimes impossible to find and erase the target code corresponding to a given subject address. In some situations, optimization is applied during the transformation, which results in a transformation that can no longer be accurately associated with the range of subject addresses it represents. In these situations, if the subject program rewrites its code at a particular subject address, the translator has no way of identifying which individual translated target code should be invalidated. In addition, secure erasure of translated target code in a multi-threaded environment can pose additional problems.

Techniques related to code rewriting are described in International Publication No. WO05 / 008487. Although these techniques are useful, the present invention handles the PLT update by techniques such as those described in International Publication No. WO 05/008487 due to the large concentration of code rewriting that occurs in runtime PLTs. It was confirmed that this could be an inefficient method. Such techniques may ensure that invalid translated target code is not executed, but when using these techniques to handle PLT updates, control flow management is in terms of processor and memory resources. It turned out to be expensive.

  In addition, the inventor found that the PLT update method used by the dynamic linker in the Solaris operating system is a standard dynamic linked program compared to the dynamic linker in some other operating system. It has been confirmed that it significantly increases the number of partitions required to run.

A method for making dynamically linked function calls for subject program code conversion is provided with a computer device that utilizes the method. In a preferred embodiment, it is possible to set a link from a function call to a subject code function in the subject code using the function link table without generating target code corresponding to the intermediate control structure. . A computer device that includes a translator that serves to convert subject code into target code may be configured to identify dynamically linked function calls in the subject program and to perform the function And target code that characterizes the association based on information aggregated in a function linkage table by a translator executing the function may be generated.

Preferred embodiments of techniques for making dynamically linked function calls allow for conveniently associating dynamically linked function calls in the subject code with the code that performs the function. The preferred embodiment may reduce processing and memory overhead associated with the technology, as known from WO05 / 008487 for code rewriting .

  Accordingly, the present invention improves the performance of a computer system, for example, while performing program code conversion.

  According to the present invention there is provided an apparatus and method as set forth in the appended claims. Preferred features of the invention will become apparent from the dependent claims and the following description.

In one aspect, a computer device that receives a target processor and subject code for execution on the subject processor and generates target code for execution on the target processor comprising a translator configured to, translator, (a) through an intermediate control structures in the subject code to subject linker code configured to pass subject control flow, one or more dynamic receiving a subject code comprising a linked subject function calls, wherein said dynamically linked function calls via an intermediate structure, the subject code to perform the functions can Fit related Yes, (b) Received subject code Identifying such dynamically linked function calls in and executing such dynamically linked function calls the corresponding function without generating target code corresponding to the intermediate control structure A computer device configured to perform association with a code is provided.

The translator identifies dynamically linked subject function calls in the received subject code, collects and receives link information regarding dynamically linked function calls in the first transformation of the received subject code May be configured to use information collected in subsequent conversions of the subject code. The computing device may be configured to pass control flow from the identified function call to code executing the corresponding function using information collected in subsequent transformations.

The computing device includes one or more dynamically linked subject functions configured such that the translator passes subject control flow to the subject linker code via a subject code procedure linkage table (PLT). When receiving subject code that includes a call, these function calls are identified by the translator in the received subject code and execute the corresponding function without generating target code corresponding to the PLT. It may be configured to be associated with.

In another aspect, there is provided a method of program code conversion performed in the target processor, the method comprising: receiving a subject code, subject code received, the intermediate in the subject code One or more configured to pass subject control flow through the control structure to the subject linker code, thereby associating dynamically linked subject function calls with the subject code that executes the function Said receiving, including dynamically linked subject function calls, identifying such dynamically linked function calls in the received subject code, and target code executing in a target processor Generating Wherein, in the target processor, such dynamically linked function calls are generated that are associated with the code that executes the corresponding function without generating the target code corresponding to the intermediate control structure. Is provided.

In yet another aspect, a computer readable medium is provided for executing a method of program code conversion executed on a target processor executable by the computer recorded thereon. comprising instructions, the method comprising: receiving a subject code, subject code received is passes subject control flow through the intermediate control structure in the subject code to subject linker code, thereby configured to associate the subject function calls that are dynamically linked to the subject code to perform the function, comprising one or more dynamically linked subject function calls, to said receiving, receiving In the subject code Identifying a dynamically linked function call and generating target code for execution on the target processor, where such dynamically linked function call is: Generating associated with the code that executes the corresponding function without generating target code corresponding to the intermediate control structure.

In yet another aspect, the translator is provided, the translator receives the subject code, and configured to generate a target code to be executed on the target processor, the translator receives the subject code The received subject code is dynamically linked to the subject code that passes the subject linker code to the subject control flow through the intermediate control structure in the subject code, thereby executing the function. Including one or more dynamically linked subject function calls configured to associate the subject function calls that have been received, and in the received subject code, such dynamically linked function calls To identify Configured and configured to generate target code that executes on the target processor, where such dynamically linked function calls can generate target code corresponding to the intermediate control structure. Associated with code that executes the corresponding function without generating it.

  The above is a summary of various aspects of embodiments of the invention. This is provided as an introduction so that those skilled in the art may more quickly understand the detailed discussion of the invention that follows, and by no means limits the spirit of the claims appended hereto It is not something that was intended.

It is a block diagram which shows the apparatus with which embodiment of this invention is applied. It is the schematic of the conversion unit used for embodiment of this invention. It is a block diagram which shows the apparatus used for embodiment of this invention. It is a flow schematic diagram explaining an example of a method of performing a function call.

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an embodiment that is presently preferred.
The following description is provided to enable those skilled in the art to make and use the invention, and describes the best mode of carrying out the invention, which is intended by the inventors. However, since the general principles of the present invention are defined in detail herein and improved program code conversion methods and apparatus are provided, various modifications will be readily apparent to those skilled in the art. .

With reference to FIG. 1, the subject program 17 is intended to be executed on a subject computing platform 1 having a subject processor 3. However, using the target computing platform 10 instead, the subject program 17 is executed via a translator code 19 that performs program code conversion. The translator code 19 performs code conversion from the subject code 17 to the target code 21 to make the target code 21 executable on the target computing platform 10.

As is well known to those skilled in the art, the subject processor 3 has a set of subject registers 5. The subject memory 8 stores, among other things, a subject code 17 and a subject operating system 2. Similarly, exemplary target computing platform 10 of Figure 1, the target processor 13 having a plurality of target registers 15, the target operating system 20, subject code 17, translator code 19, and is converted And a memory 18 for storing a plurality of operational components including target code 21. Target computing platform 10 is typically a microprocessor-based computer or other suitable computer.

In one embodiment, the translator code 19 optimizes the subject instruction set architecture (ISA) subject code into another ISA transformed target code with or without optimization. An emulator that converts. In another embodiment, the translator code 19 functions as an accelerator that transforms the subject code into target code, each code being the same ISA, by performing program code optimization.

The translator code 19 is suitably a compiled version of the source code that implements the translator and is executed on the target processor 13 in conjunction with the operating system 20. The structure shown in FIG. 1 is exemplary only, for example, that software, methods, and processes according to embodiments of the present invention may be implemented as code within or subordinate to operating system 20. I want you to understand. The subject code 17, translator code 19, operating system 20, and memory 18 storage method may be any of a wide variety of types as known to those skilled in the art.

In the apparatus according to FIG. 1, program code conversion is performed dynamically at runtime and is executed on the target architecture 10 with the target code 21 being executed. That is, the translator code 19 is executed inline with the converted target code 21. That through the translator code 19 to execute the subject program 17 includes two different types of code, executing the translator code 19 and the target code 21 alternately. Thus, the target code 21, based on the subject code 17 stored in the conversion program being is produced through the runtime by the translator code 19.

In one embodiment, the translator code 19 executes the subject program 17 as the target code 21 on the target processor 13 while subject code, such as the subject processor 3, and particularly the subject register 5. Emulate the relevant parts of architecture 1. In a preferred embodiment, at least one global register store 27 is provided (also referred to as subject register bank 27 or abstract register bank 27). In a multiprocessor environment, optionally more than one abstract register bank 27 is provided according to the subject processor architecture. A representation of the subject state is provided by the components of translator code 19 and target code 21. That is, the translator code 19 stores the subject state in various explicit programming language devices such as variables and / or objects. Compared to this, the converted target code 21 provides a subject processor state that is implicitly stored in the target register 15 and storage area 18, and these target register 15 and storage area 18 Manipulated by the target instruction of the target code 21. For example, the low level representation of the global register store 27 is just an area of allocated memory. However, in the source code of the translator code 19, the global register store 27 is a data array or object that can be accessed and manipulated at a high level.

The term “basic block” will be well understood by those skilled in the art. A basic block is a code section with exactly one input point and exactly one end point, which restricts the block code to a single control path. For this reason, basic blocks are useful basic control flow units. Suitably, the translator code 19 divides the subject code 17 into a plurality of basic blocks, each basic block being a sequence between the first instruction at a single input point and the last instruction at a single end point. Instruction set (such as jump, call, or branch instruction). The translator code 19 may select only one of these basic blocks (block mode) or a group of basic blocks (group block mode). One group block suitably includes two or more basic blocks, and these basic blocks are collectively processed as a single unit. Furthermore, the translator may form iso blocks that represent the same basic block of the subject code with different input conditions.

  In the preferred embodiment, the intermediate representation tree is generated based on the subject instruction sequence as part of the process of generating the target code 21 from the original subject program 17. The IR tree is an abstract representation of the operations computed and performed by the subject program. At a later time, the target code 21 is generated based on the IR tree. The set of IR nodes is actually an acyclic directed graph (DAG), but is commonly referred to as “tree”.

As will be appreciated by those skilled in the art, in one embodiment, the translator code 19 is implemented using an object oriented programming language such as C ++. For example, IR nodes are implemented as C ++ objects, and references to other nodes are implemented as C ++ references to C ++ objects corresponding to these other nodes. Thus, the IR tree is implemented as a collection of IR node objects that contain various references to each other.

Further, in the embodiment being discussed, IR generation uses a set of abstract register definitions that correspond to specific functions of the subject architecture, and subject program 17 is subject to It is intended to be executed on the architecture. For example, a unique abstract register definition exists for each physical register on the subject architecture (ie, subject register 5 in FIG. 1). As such, the abstract register definition in the translator can be used as a C ++ object that includes a reference to an IR node object (ie, an IR tree). The set of all IR trees referenced by a set of abstract register definitions is denoted as a working IR forest (“forest” refers to a forest containing multiple abstract register roots and these abstract registers (Each root refers to one IR tree). These IR trees and other processes appropriately form part of the translator code 19.

FIG. 2 shows the translator code 19 in more detail when executed on the target computing platform 10. As discussed above, the front end of the translator code 19 includes a decoder unit 191, which decodes the currently required section of the subject program 17 to produce a plurality of subject code blocks 171a, 171b. , 171c (each of these subject code blocks typically includes one basic block of subject code), decoder information 172 for each subject block, and included in the subject block, and A subject instruction may be provided to assist in operation at a later point in code 19. In one embodiment, the IR unit 192 in the core of the translator code 19 generates an intermediate representation (IR) based on the decoded subject instruction, and optimization is performed on the intermediate representation accordingly. An encoder 193 as part of the back end of the translator code 19 generates (installs) a target code 21 that can be executed by the target processor 13. In this simplified example, three target code blocks 211a-211c are generated, and equivalent to executing the subject code blocks 171a-171c on the subject platform 1, on the target platform 10. Executed. The encoder 193 can also generate a header code and / or footer code 212 for some or all target code blocks of the target code blocks 211a-211c, and the header code and / or footer. Code 212 performs functions such as setting the environment in which the target block operates, and returning control to translator code 19 as needed.

FIG. 3 is a more detailed schematic diagram illustrating an apparatus as used in accordance with an embodiment of the present invention. In the illustrative example of FIG. 3, the translator code 19 is configured to perform a SPARC to x86 conversion.

  The subject code 17 includes a subject execution file 17a to be converted into the target code 21a. The subject execution file 17a may sequentially refer to a number of subject libraries including a library with ownership and / or a system library, and may use a function therein. Two exemplary libraries 17b, 17c are shown.

  The subject execution file 17a has an execution file format that is compatible with the operating system of the subject processor. Typically, the subject execution file 17a includes a body of code 17a_1 and a header 17a_2. The header 17a_2 provides information about the body of the code 17a_1, for example, that information is useful for analyzing the subject execution file, and to perform dynamic linking when the subject execution file 17a is executed Information used. Although referred to as a “header”, the header 17a_2 may exist completely or partially away from the first part of the executable file 17a.

  In the specific example for explaining FIG. 3, the subject execution file 17a is configured according to an executable link format (ELF). The ELF standard is widely used, and the header 17a_1 of the file having this structure includes information on the procedure link table (PLT) 17d related to the subject execution file 17a.

When the subject code 17 is executed natively on the subject processor 3, the call to the function libraries 17b and 17c in the subject execution file 17a is performed by using the PLT 17d (PLT) and the subject linker code 17e. Is done. In this sense, the subject linker code 17e uses the PLT 17d as an intermediate control structure, and processes dynamically linked functions in the subject execution file 17a.

The subject function call is configured to pass control flow to the subject linker code 17e, which rewrites link information in the PLT 17d associated with the subject function call , thereby executing the function. It is configured to link subject function calls to subject code.

The procedure in which the PLT 17d is used to link the function call of the subject execution file 17a to the function of the subject library 17b when the subject code is executed natively on the subject processor is the introductory part of this specification. This procedure will be known to those skilled in the art. Additional information regarding the use of runtime links and PLTs in the Solaris operating system can be found below.

http: // docs. sun. com / app / docs / doc / 817-1984 / 6mhm7pl1b
FIG. 3 also shows the subject code for executing the link check function, which will be referred to as the link auditor 17f hereinafter. In the Solaris operating system, the link auditor 17f can monitor the operation of the linker by using code that is compatible with the link check interface provided by the operating system. The Solaris link inspection interface is known as rtld-audit. More information on rtld-audit can be referenced below.

http: // docs. sun. com / app / docs / doc / 817-1984 / 6mhm7pl24
A link auditor that conforms to the rtld-audit interface is loaded as an integral part of the executable, and the test routines it contains are automatically executed by the subject linker code 17e at various stages of linker execution. Called. Using the rtld-audit interface, the link auditor can access information about the loaded object, such as the subject code execution file 17a and the subject libraries 17d and 17c. In addition, the link auditor can access information about the relationships formed between such loaded objects, as well as other information related to the communication of information between the application and the library. Is possible. More information can be referenced below.

http: // docs. sun. com / app / docs / doc / 806-0641 / 6j9vukujm
The link auditor can also monitor individual invocations of function calls and their return values during the PLT update performed by the linker.

When executed natively on the subject processor 3, a function call in the subject library 17d will pass the subject control flow to the PLT 17d and then to the subject linker code 17e. The subject linker code 17e rewrites the link information specific to the PLT 17e associated with the subject function call , so that subsequent calls to the PLT input for the subject function are replaced with functions specific to the subject library function 17d. It will link to the relevant subject code for execution.

Generation of Function Link Table Using Link Auditor for Monitoring Linker Operation Before generating the target code 21 corresponding to the subject execution file 17a, the translator code 19 includes the header 17a_1 of the subject execution file 17a. And / or by performing one or more scans of the subject execution file 17a to collect information about the subject execution file 17a. The translator code 19 uses the collected information to identify the PLT 17d associated with the subject execution file 17a.

After the translator code 19 has gathered information about the subject execution file 17a, the translator code 19 is run through the subject execution file 17a for the first time and is dynamically linked in the subject execution file 17a when operating as such. Set up a link between a function call and the code that executes the corresponding function.

When the translator code 19 operates via the subject executable 17a, each dynamically linked function call found in the subject code 17a is a function link table (FLT) held in the translator code 19. ) 19a. As expected in the first conversion of subject code 17a, if a function call occurs in FLT 19a where there is no input, the control flow of subject code 17 proceeds to linker code 17e via PLT 17d. . The translator code 19 can then continue to operate through code that performs the function.

Linker 17e passes link information to link auditor 17f, and translator code 19 uses this information to add input to FLT 19a. In particular, the translator code 19 receives and stores the identifier of each function called by the subject execution file 17a and the location of the function. Each input in the FLT 19a comprises a function identifier and a corresponding function location. However, the translator code 19 does not generate target code that includes conversion of the update of the PLT region 17d by the linker code 17e.

In the exemplary embodiment described above, the translator code 19 uses a link auditor 17f that is compatible with the rtld-audit interface in building the FLT 19a. However, in other embodiments, another technique for identifying the behavior of the linker may be used, thereby entering and maintaining the FLT 19a.

Generation of the function link table - in the direct monitoring further exemplary embodiment of the linker operation detects rewrite of the PLT 17d, and executes a subject function that is dynamically linked to be called by the subject executable 17a Another method may be used to confirm the position of the code. In such an embodiment, the translator code 19 may authenticate the PLT from the file format information of the executable file. Using information about the location of the PLT region, the translator can identify the behavior of the linker, such as rewriting the PLT by detecting a unique subject code instruction sequence. In an example converted from SPARC, a cache flush instruction with a specific subject instruction sequence that affects the authenticated PLT region may be detected.

Cache flush instructions subject code instructions from PLT to the linker, when the control flow in the subject code is passed, and a linker is executed if Ru rewritten PLT input in response. Once the proper sequence of flashes has occurred, the translator reads the rewritten PLT region and determines the address of the code that executes the function called by the subject execution file. This address can be used to create an association between a dynamically linked function call in the subject execution file and the code that executes the function. However, the translator does not generate target code corresponding to the rewriting of the intermediate control structure provided by the PLT region. As described above, the translator can store the function identifier and the address of the code that executes the function in the FLT.

Use of Information in Function Link Tables In a standard application, translator code 19 encounters subject code 17 that includes one or more dynamically linked function calls with FLT inputs formed. It can happen very much. For example, the translator may be required to convert the pre-converted portion of the subject code again. In this situation, a function call is encountered in which the corresponding input is in FLT 19a. The translator code 19 uses information previously recorded in the FLT 19a to set up an association between the function call in the subject code and the corresponding code that executes the function. This association may be in the form of a direct link for convenience.

Retranslation of a particular function call bypasses both PLT 17d and linker code 17e, and translator code 19 effectively translates the dynamically linked function call into the associated code that executes the function. Allows association. That is, associating a function call in the subject code with the corresponding code that executes the function using FLT does not involve generating target code corresponding to the intermediate control structure in the subject code. Similarly, the subject linker code 17e that rewrites link information unique to the PLT 17d related to the function call is not converted. During reconversion, the subject linker code 17e is bypassed in the subject code and is therefore not accessed by the translator code 19.

As described above, the translator code 19 enters the FLT 19a while operating through a portion of the subject code at a first time. Subsequent reconversion can be more efficient than the initial conversion because the translator code 19 bypasses the linker code 17e and utilizes information from the FLT 19a. The reconversion does not require the translator to perform an operation that inputs to the FLT 19a.

Indirect function call
Some of the dynamically linked function calls encountered by the translator may be indirect function calls. Indirect function calls are calls that depend on variable values. The variable value determines where it is called and can vary. Thus, the translator can only determine the location of the code that executes the required function at the point where the target code corresponding to the indirect function call is executed.

As described above in connection with FIG. 1, when the translator encounters a function call, the translator sets the new basic blocks. The translator can collate the information stored in the FLT with the subject address referenced by the indirect function call. If the address already exists in the FLT, the translator must have previously encountered a call to the function that the indirect function call is currently referring to. As a result, the translator can treat the basic block previously set in association with the function call to perform the same function as the newly set basic block. Allowing translators to use preconfigured basic blocks instead of newly configured basic blocks, thereby further reducing the amount of translator work required to perform Is possible.

Association of code other than subject code and function call dynamically linked in subject code In the above-described embodiment, the position held in the FLT is, for convenience, the subject code that executes the corresponding function. It was the address of the instruction. However, in another embodiment of the present invention, the FLT input may be selected by translator code 19 as an address in the FLT that points to other code that performs the corresponding function. By using FLT in this way, the translator can reduce its workload. The FLT input is
Pre-translated target code, functions in the native library 28 of the target operating system 20,
Used to indicate or generate a portion of the optimized IR known to the translator and where the target code is conveniently generated, or the location of the subject code or any one of the above May be selected by the translator to point to any one of the dereferenced variables.

The use of dereferenced variables, as described above, allows the translator to exercise more control over the association between function calls and the code that executes the corresponding function. This is desirable when the location of the code that performs a particular function is not fixed for the duration of the current call to the subject program.

In the illustrative example, translator code 19 is configured to perform a SPARC to x86 conversion. The SPARC target system library may include routines in it that execute one or more functions in which the result of the execution of the function at a particular argument is strictly defined. Such a strictly defined function is known as an ABI “dot” function, for example. umul,. It includes the area of calculation functions such as smul. These ABI dot functions are shown below.

http: // www. sparc. com / standards / psABI3rd. pdf
Since the operation of the ABI dot function is strictly defined, the translator can treat the function call specified as a call to the ABI dot function as a simple instruction having the same effect as the ABI dot function. This allows the translator to bypass the PLT completely, for example by setting the FLT input and directly associating the function call with a portion of the non-subject code that executes the corresponding function. Bypassing the PLT in this manner reduces the translator workload. Furthermore, in this example, the translator can completely avoid the work associated with handling function calls by adding code with the effect of the associated ABI dot function instead of the function call itself. is there.

Calls to subject functions that have a known correspondence with the native function library can be identified by the translator code 19, and the correspondence with the native function can be used to reduce the translator workload. Is done. For example, a call to memcpy in subject library 17c, in FLT 19a, can be associated to the position of those corresponding to native x86 in the native library 28. This reduces the conversion cost of the subject (SPARC) version of the memcpy function. In addition, the native (x86) version of the memcpy function can adapt to the complexity of the native hardware and obtain the desired effect of the function in the most efficient way for that hardware.

FIG. 4 is a flow diagram illustrating an exemplary embodiment of a method for making dynamically linked function calls. A subject code is received and read to identify the PLT region (step 101). The dynamically linked function call is identified in the subject code (step 102), and the dynamically linked function call is directed to the subject linker code that rewrites the link information associated with the subject function call in the PLT. Is configured to pass the subject control flow and thereby link the subject function call to the subject code that executes the function. The FLT performs a match on the input corresponding to the identified function call (step 103), and if the FLT contains an associated input, the method proceeds to step 107, where the target code is generated, In the target code, the function call is associated with the code that executes the function. The association set in step 107 is based on the function identifier and position as stored in the FLT. The generated target code does not include the target code corresponding to the intermediate control structure provided by the PLT.

  In step 103, if the FLT does not include an associated input for the identified function call, the link auditor may operate to obtain a function identifier and location (step 104), and / or a function identifier. And location can be obtained by monitoring the cache flush of subject code instructions (step 105). The information obtained in step 104 and / or step 105 is then input to the FLT (step 106). Thereafter, step 107 is executed based on the information obtained in step 104 and / or step 105.

In the exemplary embodiment described in detail above, the subject linker code is in the body of the subject code accessible to the translator . However, in other embodiments, the linker's ability to perform linking in the subject code is specifically described for execution on a target processor, such as the linker code 19e shown in FIG. It may be provided by a translator that uses a different target code. Furthermore, although the exemplary embodiments focused on PLTs associated with subject executables, subject libraries 17b, 17c may also include intermediate control structures in the form of their own PLT regions. . The methods and apparatus described herein can be equally applied to these identifiable portions of code that include PLT regions and intermediate control structures and cause corresponding problems. It is.

By using the techniques described herein, the translator code 19 controls the subject code to generate a transformation corresponding to the update of indirect link information in the intermediate control structure, such as PLT. no need to follow the flow, hence, it is possible to avoid processing and memory cost of part of the conversion of the subject code containing a large number of concentration of codes are rewritten et at runtime.

In addition, an efficient method has been described for dealing with situations where the translator performs subject code execution that involves updating indirect link information.
In particular, the present invention has developed methods and units useful in computer systems that perform program code conversion. Such methods and units are particularly useful in connection with computer systems configured as run-time translators that provide dynamic binary conversion of subject program code to target code.

The invention extends to a translator configured to perform any of the methods specified herein. Similarly, the invention extends to a computer readable recording medium having recorded computer-implementable instructions for performing any method specified herein.

  At least some embodiments of the present invention may be configured independently using dedicated hardware, and words such as “module” or “unit” as used herein are not limited thereto. However, it may include a hardware device such as a field programmable gate array (FPGA) or application specific integrated circuit (ASIC) that performs a specific task. Alternatively, the elements of the present invention may be configured to be present on an addressable recording medium and may be configured to be executed on one or more processors. Accordingly, the functional elements of the present invention, in one embodiment, include, by way of example, software elements, object-oriented software elements, class elements and task elements, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, Elements such as firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables may be included. Furthermore, although preferred embodiments are described with reference to the elements, modules and units described below, such functional elements may be combined into fewer elements or divided into additional elements. May be.

  Various features of the apparatus and method of the present invention are described separately in each of the above-described embodiments. However, it is the intent of the inventor of the present invention that separate aspects of each embodiment described herein can be combined with other embodiments described herein.

  Those skilled in the art will appreciate that various adaptations and modifications of the preferred embodiments as described can be made without departing from the scope and spirit of the invention. Accordingly, it is to be understood that the invention may be practiced otherwise than as specifically described herein within the scope of the appended claims.

  While several preferred embodiments have been shown and described, various changes and modifications will be apparent to those skilled in the art without departing from the scope of the invention. It will be understood that this can be done.

  Attention is directed to all documents filed at the same time or prior to this specification in connection with this application, and to documents published for public viewing of this specification, and the contents of all such documents are , Incorporated herein by reference.

  All features disclosed in this specification (including any appended claims, abstract, and drawings) and / or all steps of any method or process so disclosed are Can be synthesized in any combination, except combinations where at least some of the features and / or steps are mutually exclusive.

  Each feature disclosed in this specification (including any appended claims, abstract, and drawings) is intended to have the same, equivalent, or similar purpose unless explicitly stated otherwise. Can be replaced by another feature treated in. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

  The present invention is not limited to the details of the foregoing embodiments. The present invention is directed to any novel or any novel combination of features disclosed herein (including any appended claims, abstract and drawings), or any such novel combination. It extends to any novel or any novel combination of any method or process steps that have been made.

Claims (20)

A computer device,
A target processor;
Memory and
The memory is
A target operating system running on the target processor;
A translator executing on the target operating system, the translator holding a function link table;
The translator causes the computer device to dynamically convert subject code into target code executed by the target processor, the subject code being an intermediate control structure in the subject code Including one or more dynamically linked subject function calls configured to pass subject control flow to the subject linker code via a procedure linkage table;
The translator is connected to the computer device.
Detecting a modification to a procedure linkage table associated with a dynamically linked subject function call in the subject code;
Identifying the dynamically linked function call in the subject code, and generating the identified dynamically linked function call without generating target code corresponding to the intermediate control structure. Associating with code executing a corresponding function that is not the target code corresponding to an intermediate control structure;
In response to the detection of the modification, the function link table stores an identifier corresponding to the dynamically linked function call and a position of code for executing the dynamically linked function call. The computer device.   The translator identifies dynamically linked subject function calls in the subject code to the computing device, and link information regarding the dynamically linked function calls in a first transformation of the subject code And implementing the use of the collected information in a subsequent conversion of the subject code.   The translator enables the computing device to pass control flow from the identified function call to the code executing the corresponding function using the collected information in a subsequent transformation; The computer apparatus according to claim 2.   The translator causes the computer device to store information about the identified function call in a function link table accessible to the translator in the form of an identifier for the identified function call; and The computer apparatus according to claim 1, wherein storage of a position of code for executing the identified function is realized in a link table.   The translator enables the computing device to collate the function link table against an input corresponding to each identified function, wherein the function link table includes an input corresponding to the identified function; The computer apparatus according to claim 4, wherein the information stored in the function link table is used to realize associating the function call with a code that executes the corresponding function.   The translator collects link information about the function call by monitoring the operation of the subject linker code or detecting a cache flush instruction of a specific subject code instruction sequence. The computer apparatus according to claim 2 to be realized.   The translator establishes a direct link between the dynamically linked function call and the code executing the function in the computer device in association with the code executing the corresponding function. The computer apparatus according to claim 1, wherein:   The translator causes the computing device to place, in the function linkage table, a location of native code that executes the identified function, a location of pre-transformed target code that executes the identified function, and the The location of the optimized intermediate representation part known to the translator from which the target code can be generated to execute the identified function The computer apparatus according to claim 4, wherein storage of one or more of the above is realized.   The translator identifies to the computing device a dynamically linked function call associated with a function, and replaces the dynamically linked function call with code that performs the corresponding function. The computer apparatus according to claim 1, which is realized.   The translator is one or more dynamically linked to the computing device configured to pass a subject control flow to the subject linker code via the subject code procedure linkage table (PLT). A subject code including a subject function call, identifying the dynamically linked function call in the received subject code, and sending the dynamically linked function call to the PLT. The computer apparatus according to claim 1, which realizes associating with the code that executes the corresponding function that is not the target code corresponding to the PLT without generating the corresponding target code. A method of dynamically transforming subject code into target code for execution on a target processor, wherein the subject code is subject control flow to subject linker code via an intermediate control structure in the subject code Including one or more dynamically linked subject function calls configured to pass
Detecting a modification to a procedure linkage table associated with a dynamically linked subject function call of the subject code;
Generating target code for execution in the target processor, wherein the dynamically linked function call does not generate target code corresponding to the intermediate control structure in the target processor; Said generating step associated with code that executes said corresponding function that is not said target code corresponding to said intermediate control structure;
In response to detection of the modification, an identifier corresponding to the dynamically linked function call and a dynamically linked function in a function link table held in a translator executing on the target operating system Storing the location of the code that performs the call;
Performing the method. In the first conversion of the subject code, link information relating to the identified dynamically linked function call, the is collected for use in the subsequent conversion of the subject code, according to claim 11 Method. In a subsequent conversion, the information collected in the first conversion from the identified function call to the code that performs the corresponding function, is used to pass control flow, according to claim 12 the method of. The computer is
Storing information about the identified function call in a function link table;
Collating the function link table for an input corresponding to each of the identified functions, and if the function link table includes an input corresponding to the identified function, the information stored in the function link table is using comprising performing the step of associating the function call to the code that performs the corresponding functions, method of claim 11. The step of generating the target code in the target code, including the dynamic linked function calls, the step of setting a direct link between the code for performing the function, according to claim 11 The method described in 1. The computer is
In the function link table, the position of native code that executes the identified function, the position of the pre-transformed target code that executes the identified function, and the position of the portion of the optimized intermediate representation A group including the location of the optimized intermediate representation portion from which the target code is generated and the identified function can be executed from the portion, and a dereferenced variable Performing the step of storing one or more selected from
The dereferenced variables include subject code that executes the identified function, native code that executes the identified function, pre-transformed target code that executes the identified function, A portion of an optimized intermediate representation known to the translator, the optimized intermediate known to the translator capable of generating target code from the portion and executing the identified function Related to the position of one of the parts of the representation,
The method according to claim 14 . The computer is
Identifying dynamically linked function calls associated with the function;
The method of claim 12 , comprising: replacing the dynamically linked function call with code that executes the corresponding function. The computer is
Receiving one or more dynamically linked subject function calls configured to pass a subject control flow to the subject linker code via a procedure link table (PLT) of the subject code; ,
Identifying the dynamically linked function call in the subject code;
Associating the dynamically linked function call with code that executes the corresponding function that is not the target code corresponding to the PLT without generating the target code corresponding to the PLT; The method of claim 12 , comprising: 19. A computer program for program code conversion executed in a target processor, wherein the computer program causes each step of the method according to any one of claims 11 to 18 to be executed. A code conversion device configured to dynamically convert a subject code into a target code to be executed on a target processor, the subject code being subject to the subject code via an intermediate control structure Including one or more dynamically linked subject function calls configured to pass a subject control flow to the linker code, the code translator comprising:
Detecting a modification to a procedure linkage table associated with a dynamically linked subject function call in the subject code;
Generating target code for execution on the target processor, wherein the identified dynamically linked function call is generated without generating target code corresponding to the intermediate control structure; The generating associated with code executing a corresponding function that is not the target code corresponding to an intermediate control structure;
In response to detection of the modification, the function link table stores an identifier corresponding to the dynamically linked function call and a position of code that executes the dynamically linked function call. The code conversion device configured as described above.

Images