Sei sulla pagina 1di 4

The Implementation of Dynamic Linking in Dynamic Binary Translation Systems

AbstractDynamic binary translation (DBT) is a commonly used technology in virtual machines. Most DBT systems, like Dynamo, can only translate programs statically linked but not ones dynamically linked. Statically linked programs will lead to expansion of binary codes,which is the indirect reason of loss on performance. During the research, we came across some challenges related with operating systems, compilation and architecture. And we have developed a module and had it tested on our DBT system, CrossBit. The statistics show that CrossBit with dynamic linking reduces the number of translated blocks and execution time.

INTRODUCTION

Binary translation is a commonly used technology in virtual machines. It converts binary code of one ISA (source binary code) to the binary code of another ISA (target binary code) during the runtime. And the target code will be executed right after the conversion. Dynamic linking includes two parts: dynamic loading and dynamic resolving. Dynamic loading means that dynamic link library is loaded into memory when needed .Dynamic resolving means that the address of dynamic function is resolved when the function is right to be executed. Our test platform, CrossBit[1,2,8,9], runs on Linux. The whole paper is based on the Linux environment. The dynamic link libraries and executable files are in Executable and Linkable Format (ELF). BACKGROUND
ELF file has two parallel views, linking view and execution view.

IMPLEMENTATION We have designed a module of managing dynamic link libraries as a plug-in for DBT systems. When the source file is loaded into memory, the module will check whether the source file is dynamically linked. If it is, the module is responsible for the part of dynamic linking. This module mainly contains three parts: dynamic loading, dynamic resolving and execution of dynamic function, which make up the whole process of dynamic linking.

A. Dynamic Loading
One characteristic of dynamic linking is that the dynamic link libraries be loaded into memory when needed. The DBT systems didnt load any dynamic link library until it detects a first call to some function in dynamic link library. Each library is identified by its name, in the format of a string. Dynamic section records the starts address of string table and a string table offset indexing

dynamic link library. With this information,the name of dynamic link libraries can be obtained easily. And according to the names, the module searches these libraries in the lib path defined by the system or user. Then the dynamic link libraries are loaded into memory in the linking view, which means that the libraries are loaded section by section. If the source program needs to invoke functions from more than one dynamic link library, they will be load at the same time and be managed by a list.

B. Dynamic Resolving
Dynamic resolving is another characteristic of dynamic linking, which means the real address of dynamic function is calculated right before the function being executed. The first step of resolving is to get the name of the function. This procedure is similar to the one of getting the name of dynamic link library. The difference is that the string table offset is given in the member st_name in symbol table entry. Moreover, the index of the entry is defined during compiling. It can usually be obtained from registers or stack simulated in memory. The second step is to calculate the functions address with the name obtained before. This step needs dynamic link librarys string table, symbol table and hash table. (a) Hash the string to an integer value. Use this integer to index the hash table and get the symbol table entry index, which is also an integer. Jump to part (c). (b) Entering this part means that hash conflict has happened before. Use the integer value, which was used to index symbol table, as the input for the secondary hash to get a new integer. Then go to part (c).

(c)Index the symbol table with the integer value from hash table and get the string table offset from the member st_name from the corresponding entry.

(d)Get a string according to the string table offset. If the string is the different from the one representing the function, hash conflict happened. Jump to part (b). Otherwise, we have found the correct symbol table entry. And the value of st_value in the entry is the address of the function.

C. Function Wrap
With the function address, we adopt the method of function wrapping to invoke the dynamic function. We define a wrap for every function prototype. The DBT systems initial the wrap with the address resolved and call the function with its pointer. In DBT systems, we cant ensure the parameters being passed correctly because the architectures of source and target machines may be different. As the DBT systems have simulated the source register files and stack in memory, we can read parameters from simulated registers and stack, invoke the dynamic function and put the return value to simulated registers or stack according the source machines rules for passing parameters. Because of the way in which we wrap the dynamic functions, there is no need for us to put the parameters in target machine registers or stack.

D. Some Special Functions


Some special functions, like printf, have variable types and numbers of parameters. Another type of special function is related with platform on which it runs, like __libc_start_main. Its functionality is to initialize the environment for the program to start and terminate properly.

IV. PERFORMANCE
We have implemented dynamic linking on our DBT system, CrossBit, to test its effect on performance. The configuration of test machine is Intel(R) Pentium(R) 4 CPU 2.80GHz, memory: 756.0 MB. And the test programs are mcf, bzip2 and gzip from SPEC2000 benchmarks. The cache size is set large enough for target code to avoid some blocks being translated repeatedly. The number of translated blocks of dynamically linked programs is reduced remarkably, ranging from 20% to 50% compared with the one of statically linked programs. Thats because it uses the local libraries on target machine, which dont need to be translated. And the performance is improved in a certain extent, but not as remarkably as the number of translated blocks. There are some reasons for this phenomenon. The most important one is that the dynamic linking just saves the translation time of the code in dynamic link libraries. But the translation time is much less compared to the execution time in DBT systems. And the invoking of dynamic functions also needs time. CONCLUSION The DBT systems with dynamic linking technology can expand its scope of application, as well as improve the performance. But it still has some challenges. One of the challenges is to provide a general method to process function calls of all prototypes. Now there are large numbers of function prototypes in each library. And the change of one function prototype in future will affect the correctness of dynamic linking. So we have to update our dynamic linking module periodically. Nevertheless, our dynamic linking module supports dynamically linked program migration on heterogeneous platforms. We consider it worthwhile.

Potrebbero piacerti anche