A simulator that accepts binary object files as input must incorporate a technique for linking calls to functions that reside in a shared library. When the current implementation of Sim386 encounters a call to a function in a shared library, the simulator intercepts the function call and processes the request locally. For example, a call to the shared library function printf is intercepted and an actual printf is executed by the simulator. For simplicity, the current implementation restricts the printf to a single integer parameter. To fully simulate an ELF binary, functionality for performing dynamic linking must be incorporated into the simulator.
In general, an ELF executable file can specify a program interpreter in the ELF program header that is loaded into memory first; this interpreter then controls the environment for the application. The interpreter is specified by setting the p_type field to PT_INTERP for the appropriate segment structure in the program header; figure 2.7 illustrates the segment structure. The PT_INTERP value in the p_type field indicates to the system that this entry is a segment that specifies a path to a program interpreter. The program interpreter is set to the system's dynamic linker when dynamic linking is used by the ELF executable. The ELF executable has stored data in the .dynamic, .hash, .got, and .plt sections that assists the dynamic linker in the running of the ELF executable. Figure 2.9 gives a brief description of these sections. Linking calls to functions in the shared library represents a subset of the services that the simulator must perform to truly emulate dynamic linking. In simulating the dynamic linking, Sim386 must handle all services requested from the ELF executable to the shared object library.