Implicit Dynamic Linking or loading
Implicit linking or Implicit dynamic loading in the system process, where the loader of operating system loads the DLL executable at the same time as the executable that uses it.
Dynamic linking happens in two stages.
- Stage #1 happens during compilation/build time and
- stage #2 happens during loading time.
Any symbol which is a part of external libraries goes through a different process than any symbol which are present in the other object files. A symbol or function or variable links to the other object file or links to a static library file is linked directly as a payload to the binary. Functions are placed in the .text section and variables are in .data/.bss/.rodata sections. Then they are resolved by the offset address. The effective address is the load address of this section sum with the offset address.
A symbol or function or variable which is not present in object files are the external symbols and they are linked via import libraries. We have to specify the library name with the argument -l
Let us consider linking printf and getchar function.
Libc binary holds a list of functions which can be used by application. Linker adds few sections to the binary to hold information about these functions. String name the function, offset address, index etc are added in the dynamic sections and library is generated. Now we are linking our application along with this libc. Linker checks which functions are not available and if they are present in the library. Here printf and getchar are not present in the object modules and they are present in the dynamic sections of libc. So linker takes these two as resolved symbols. Linker add some sections to tell that libc is the library binary needed when this application is going to execute and these two function has to be resolved by dynamic loader/linker at that time.
Linker adds some sections that are used in dynamic loading purpose. These contain the name of the library, the names of imported functions, offset address entry and table to map virtual address. It also adds a stub table to resolve the symbols. Linker links the function to the procedure linkage table. This table contains a lookup table. Control jumps to the table and from here it jumps to the actual address. Initially the function addresses are zero. These entries will be resolved by dynamic linker.
Dynamic loader loads the executable in virtual memory then it checks the sections for dynamic loading. It checks the library file path and also loads the library in virtual memory. Now it checks the table of imported functions needed by the application. Here dynamic linking process happens. Loader checks the function printf and looks up in the export sections of libc. Libc has the function entry and it has a load address and offset. So virtual address is calculated and it is places in the procedure linkage table. Here actual linking process is completed for printf. Same way getchar also gets the proper address. This way all the entries in procedure linkage table are filled and linking process comes to an end. There after the application is ready to run. So the loader jumps to the entry point of the application.
 
Dynamic sections in C App (Linux)
Dynamic section at offset 0xf14 contains 24 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 ...
 0x6ffffef5 (GNU_HASH)                   0x80481ac
 0x00000005 (STRTAB)                     0x804822c
 0x00000006 (SYMTAB)                     0x80481cc
 0x0000000a (STRSZ)                      84 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000015 (DEBUG)                      0x0
 0x00000003 (PLTGOT)                     0x804a000
 0x00000002 (PLTRELSZ)                   32 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x80482b4
 0x00000011 (REL)                        0x80482ac
 ...
 0x00000000 (NULL)                       0x0
Relocation section '.rel.dyn' at offset 0x2ac contains 1 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
08049ffc  00000306 R_386_GLOB_DAT    00000000   __gmon_start__
Relocation section '.rel.plt' at offset 0x2b4 contains 4 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
0804a00c  00000107 R_386_JUMP_SLOT   00000000   printf
0804a010  00000207 R_386_JUMP_SLOT   00000000   getchar
0804a014  00000307 R_386_JUMP_SLOT   00000000   __gmon_start__
0804a018  00000407 R_386_JUMP_SLOT   00000000   __libc_start_main
The decoding of unwind sections for machine type Intel 80386 is not currently supported.
Symbol table '.dynsym' contains 6 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 00000000     0 FUNC    GLOBAL DEFAULT  UND printf@GLIBC_2.0 (2)
     2: 00000000     0 FUNC    GLOBAL DEFAULT  UND getchar@GLIBC_2.0 (2)
     3: 00000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
     4: 00000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.0 (2)
     5: 0804850c     4 OBJECT  GLOBAL DEFAULT   15 _IO_stdin_used
Dynamic sections in Libc(Linux)
Symbol table '.dynsym' contains 2394 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 00000000     0 OBJECT  GLOBAL DEFAULT  UND __libc_stack_end@GLIBC_2.1 (34)
     2: 00000000     0 OBJECT  GLOBAL DEFAULT  UND _rtld_global@GLIBC_PRIVATE (35)
   .....
   640: 0004d410    52 FUNC    GLOBAL DEFAULT   12 printf@@GLIBC_2.0
   .....
   919: 00067630   233 FUNC    GLOBAL DEFAULT   12 getchar@@GLIBC_2.0
Dynamic sections in C App (Windows)
Windows world uses PE/COFF format for the executable binary. The section names and data formats are different but the mechanism is same. Linker adds sections various sections to hold the dependent library name, names of these external functions, effective address of these functions, offset table, procedure linkage table etc to the ELF binary.
 
Windows Libc import library
 
List of import symbols by implicit app
 
Dynamic sections in Libc(Windows)
List of export symbols by libc/msvcrt.dll
 
Explicit Dynamic Linking or loading
Operating system loads the DLL on demand at runtime. An executable that uses a DLL by explicit linking must explicitly load and unload the DLL. It must also set up a function pointer to access each function it uses from the DLL. Unlike calls to functions in a statically linked library or an implicitly linked DLL, the client executable must call the exported functions in an explicitly linked DLL through function pointers. Explicit linking is sometimes referred to as dynamic load or run-time dynamic linking.
Windows Explicit Linking
When application does not links the external symbol by import library rather it loads the DLL at runtime. It does the same mechanism as operating system does during loading of the implicit linked DLL calls.
This is done by using Win32 APIs like :
- LoadLibrary() - loads and links a input library form the DLL path, or current path,
- GetProcAddress() - finds the symbol/function address by its name for a loaded DLL
- FreeLibrary() - unloads the loaded DLL instance
Windows DLL project
 
 
 
 
Windows App project
 
 
 
 
 
 
Linux Explicit Linking
Let us consider once again math.c file for explicit linking. The steps for creating a shared library are same as that of implicit linking. 
First we compile it with position independent flag on(-fPIC). This is needed for dynamic/static linking.
$cc -fPIC -c mathlib.c -o mathlib.o
Now make a shared library with the object file.
$cc -shared -o libmath.so mathlib.o
To use this shared library in a application we need to load the library then find the function pointer address, invoke the function, and at last unload the library.
Linux provides some dynamic link library APIs to achieve this. Her are some useful frequently use APIs:
- dlopen() - loads a dynamic link binary
- dlsym() - returns the function pointer if found the function entry
- dlclose() - unloads the dynamic link binary
Linux SO project
 
Linux App project
 
SO and App build and run
 
About our authors: Team EQA
You have viewed 1 page out of 27. Your DLL learning is 0.00% complete. Login to check your learning progress.
 
 