This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
code segment, so the content of the segment does not depend on its address. The first approach is straightforward but restrictive: it generally requires that we assign a unique address to every sharable library; otherwise we run the risk that some newly created program will want to use two libraries that have been given overlapping address ranges. In Unix System V R3, which took the unique-address approach, shared libraries could only be installed by the system administrator. This requirement tended to limit the use of dynamic linking to a relatively small number of popular libraries. The second approach, in which a shared library can be linked at any address, allows users to employ dynamic linking whenever they want.
In this term paper I have explain the dynamic linker, its working, functions and implementation examples of dynamic linker like MS-DOS linkers and SunOS linkers. In computing, a dynamic linker is the part of an operating system (OS) that loads and links the shared libraries for an executable when it is executed. Dynamic linkers/loaders vary widely in functionality. Some depend on the executable storing explicit paths to the libraries. Here we explain the method in which routines that are to be dynamic loaded must be called via an OS service request. In this term paper I have explain the advantages and the disadvantages of the dynamic linking. One of the biggest disadvantages of dynamic linking involves the executables depending on the separately stored libraries in order to function properly.
In computing, a dynamic linker is the part of an operating system (OS) that loads and links the shared libraries for an executable when it is executed. The specific operating system and executable format determine how the dynamic linker functions and how it is implemented. Linking is often referred to as a process that is performed at compile time of the executable while a dynamic linker is in actuality a special loader that loads external shared libraries into a running process and then binds those shared libraries dynamically to the running process. The specifics of how a dynamic linker functions are operating system dependent.
Programmers originally developed dynamic linking in the Multics operating system, starting in 1964, and the MTS (Michigan Terminal System), built in the late 1960s
Dynamic linking involves loading the subroutines of a library (which may be referred to as a DSO (dynamic shared object) under Unix-like systems) into an application program at load time or runtime, rather than linking them in at compile time. Only a minimum amount of work is done at compile time by the linker. It only records what library routines the program needs and the index names or numbers of the routines in the library. The majority of the work of linking is done at the time the application is loaded (lead-time) or during execution (runtime). The necessary linking code is called a loader. Loader is actually part of the underlying operating system. At the appropriate time the loader finds the relevant DLLs or DSOs and adds the relevant data to the process's memory space.
Linkage editors perform linking operations before the program is loaded for execution. Linking loaders perform these same opeterations at load time. There are a number of mechanisms that can be used to accomplish the actual loading and linking of a called subroutine. A subroutine is loaded and linked to the rest of the program when it first called. This type of function is usually called dynamic linking, dynamic loading, or load on call. Linking is often used to allow several executing programs to share one copy of a subroutine or library.
For example: - run-time support routines for a high-level language like c could be stored in a dynamic link library. A single copy of the routines in this library could be execution could be linked to this one copy, instead of linking a separate copy into each object program.
Loading and calling of a subroutine using Dynamic Linking
There are a number of different mechanisms that can be used to accomplish the actual loading and linking of called subroutine. Here we explain the method in which routines that are to be dynamic loaded must be called via an OS service request. This method could also be thought of as a request to a request to a part of the loader that is kept in memory during execution of the program. The program makes a load-and-call service request to the OS, Instead of executing a JSUB instruction that refers to an external symbol. The operating system examines its internal tables to determine whether or not the routine is already loaded. If it is necessary, the routine is loaded from specified user or system libraries. Control is then passed from the OS to the routine being called as shown in fig.(c).
When the called subroutine completes its processing, it returns to its caller. The OS then returns control to the program that issued the request. After the subroutine is completed, the memory that was allocated to load it may be released and used for other purpose. When dynamic linking is used, the association of an actual address with the symbolic name of the called routine is not made until the call statement is executed.
Most MS-DOS compilers and assemblers produce object modules. These modules have the file name extension .OBJ. Each object module contains a binary image of the translated instructions and data of the program. It also describes the structure of the program. MS-DOS LINK is a linkage editor that combines one or more object modules to produce a complete executable program. By convention, this executable program has the file name extension .EXE. LINK can also combine the translated programs with other modules from object code libraries.
Record Types Description
THEADR Translator header
TYPDEF External symbols
PUBDEF and references
LNAMES Segment definition
SEGDEF and grouping
LEDATA Translated instructions
LIDATA and data
FIXUPP Relocation and linking
MODEND End of object module
SunOS actually provides two different linkers, called the link-editor and the run-time linker. The link-editor is most commonly invoked in the process of compiling a program. It takes one or more object modules produced by assemblers and compilers, and combines then to produce a single output module. This output module may be
A relocatable object module, suitable for further link-editing.
A static executable, with all symbolic references bound and ready to run.
A dynamic executable, in which some symbolic references may need to be bound at run time.
A shared object, which provides services that can be bound t run time to one or more dynamic executables.
An object module contains one or more sections, which represent the instruction and data areas from the source program. Each section has a set of attributes, such as "executable" and "writeable". The SunOS link-editor begins by reading the object modules that are presented to it to process. Section from the input files that have the same attributes are concatenated to from new section within the output file. The linker normally generates a new symbol table, and a new set of reloction instructions, within the output file. These represent symbols that must be bound at run time, and relocations that must be performed when the program is loaded.
Locating libraries at runtime
Dynamic linkers/loaders vary widely in functionality. Some depend on the executable storing explicit paths to the libraries. Any change to the library naming or layout of the file system will cause these systems to fail. More commonly, only the name of the library (and not the path) is stored in the executable, with the operating system supplying a method to find the library on-disk based on some algorithm. One of the biggest disadvantages of dynamic linking involves the executables depending on the separately stored libraries in order to function properly. If the library is deleted, moved, or renamed, or if an incompatible version of the DLL is copied to a place that is earlier in the search, the executable would fail to load. On Windows this is commonly known as DLL hell.
Dynamic linking provides the benefits
Dynamically linked shared libraries are easier to create than static linked shared libraries.
Dynamically linked shared libraries are easier to update than static linked shared libraries.
The semantics of dynamically linked shared libraries can be much closer to those of unshared libraries.
Dynamic linking permits a program to load and unload routines at runtime, a facility that can otherwise be very difficult to provide.
The runtime performance costs of dynamic linking are substantial compared to those of static linking, since a large part of the linking process has to be redone every time a program runs. Every dynamically linked symbol used in a program has to be looked up in a symbol table and resolved.
Dynamic libraries are also larger than static libraries, since the dynamic ones have to include symbol tables.
Beyond issues of call compatibility, a chronic source of problems is changes in library semantics. Since dynamic shared libraries are so easy to update compared to unshared or static shared libraries, it's easy to change libraries that are in use by existing programs, which means that the behavior of those programs changes even though "nothing has changed". This is a frequent source of problems on Microsoft Windows, where programs use a lot of shared libraries, libraries go through a lot of versions, and library version control is not very sophisticated. Most programs ship with copies of all of the libraries they use, and installers often will inadvertently install an older version of a shared library on top of a newer one, breaking programs that are expecting features found in the newer one.
1) Donovan, "System Programming", McGraw-Hill.
2) Leland L .Beck "System Software An introduction to System Programming", D.Manjula.