Beruflich Dokumente
Kultur Dokumente
An Overview
Sanjiv Malik
Type of Linking
Static Linking : All symbols resolved at the time of linking. For example, gcc static flag sets the program to be linked in static fashion. Disadvantage : Large program size Advantage : Fast processing Dynamic Linking : Symbols are resolved at the time of execution of the program. gcc by default links the program dynamically. The program size is small, but the runtime performance cost is substantial.
2009/1/26
2009/1/26
Merges object files merges multiple relocatable (.o) object files into a single executable object file that can loaded and executed by the loader. Resolves external references as part of the merging process, resolves external references. external reference: reference to a symbol defined in another object file. Relocates symbols relocates symbols from their relative locations in the .o files to new absolute positions in the executable. updates all references to these symbols to reflect their new positions. references can be in either code or data code: a(); /* ref to symbol a */ data: int *xp=&x; /* ref to symbol x */
2009/1/26
2009/1/26
Elf header magic number, type (.o, exec, .so), machine, byte ordering, etc. Program header table page size, virtual addresses for memory segments (sections), segment sizes. .text section code .data section initialized (static) data .bss section uninitialized (static) data Block Started by Symbol Better Save Space has section header but occupies no space
2009/1/26
ELF header Program header table (required for executables) .text section .data section .bss section .symtab .rel.txt .rel.data .debug Section header table (required for relocatables)
.symtab section
symbol table procedure and static variable names section names and locations .rel.text section relocation info for .text section addresses of instructions that will need to be modified in the executable instructions for modifying. .rel.data section relocation info for .data section addresses of pointer data that will need to be modified in the merged executable .debug section info for symbolic debugging (gcc -g)
ELF header Program header table (required for executables) .text section .data section .bss section .symtab .rel.text .rel.data .debug Section header table (required for relocatables)
2009/1/26
Example C program
m.c int e=7; int main() { int r = a(); exit(0); } a.c extern int e; int *ep=&e; int x=15; int y; int a() { return *ep+x+y; }
2009/1/26
m.o
main() int e = 7
.text .data
a() more system code system data int e = 7 int *ep = &e int x = 15 uninitialized data .symtab .debug
.data .bss
2009/1/26
10
source: objdump
2009/1/26 11
3: R_386_32 ep movl 0x0,%eax 8: R_386_32 x movl %esp,%ebp addl (%edx),%eax movl %ebp,%esp addl 0x0,%eax 14: R_386_32 popl %ebp ret y
2009/1/26
12
2009/1/26
13
e5 08 00 00 00 00 35 ff ff ff
55 8b 08 a1 89 03 89 03 08 5d c3
15 1c a0 04 20 a0 04 08 e5 02 ec 05 d0 a3 04
Disassembly of section .data: 0804a010 <__data_start>: 804a010: 00 00 00 00 0804a014 <p.2>: 804a014: f8 a2 04 08 0804a018 <e>: 804a018: 0804a01c <ep>: 804a01c: 0804a020 <x>: 804a020:
07 00 00 00
18 a0 04 08
0f 00 00 00
15
strong: procedures and initialized globals weak: uninitialized globals p1.c: p2.c: int foo; p2() { } weak strong int foo=5; p1() { }
strong strong
2009/1/26
16
Further improves modularity and efficiency by packaging commonly used functions (e.g., C standard library, math library) Linker selectively includes only the .o files in the archive that are actually needed by the program.
2009/1/26 17
...
Translator random.o
Archiver (ar)
libc.a
C standard library
Archiver allows incremental updates: recompile function that changes and replace .o file in archive.
2009/1/26
18
p
2009/1/26 19
2009/1/26
20
2009/1/26
21
2009/1/26
22
The runtime linker, ld.so.1, processes dynamic executables and shared objects at runtime, binding the executable and shared objects together to create a runnable process. During the link-editing of a dynamic executable, a special .interp section, together with an associated program header, are created. This section contains a path name specifying the programs interpreter. The default name supplied by the link-editor is the name of the runtime linker: /usr/lib/ld.so.1 for a 32bit executable and /usr/lib/64/ld.so.1 for a 64bit executable. The dynamic linker ld.so.1 is itself an ELF shared library. At program startup, the system maps the ld.so to a part of the address space and runs its bootstrap code.
2009/1/26
23
2009/1/26
24
During input file processing, all local symbols from the input relocatable objects are passed through to the output file image. All global symbols are accumulated internally within the link-editor. Each global symbol supplied by a relocatable object is searched for within this internal symbol table. If a symbol with the same name has already been encountered from a previous input file, a symbol resolution process is called. This symbol resolution process determines which of the two entries are kept. On completing input file processing, and providing no fatal symbol resolution errors have occurred, the link-editor determines if any unresolved symbol references remain. Unresolved symbol references can cause the link-edit to terminate. Finally, the link-editors internal symbol table is added to the symbol tables of the image being created.
2009/1/26
25
Example
$ cat main.c
extern int u_bar; extern int u_foo(); int t_bar; int d_bar = 1; d_foo() { return (u_foo(u_bar, t_bar, d_bar)); }
2009/1/26
26
Sections are the smallest indivisible units that can be processed within an ELF file. Segments are a collection of sections that represent the smallest individual units that can be mapped to a memory image by the dynamic linker ld.so.
2009/1/26
27
0x08048494
0x0804a010
2009/1/26
29
When linking a dynamic executable, one or more shared objects are explicitly referenced. These objects are recorded as dependencies within the dynamic executable. The runtime linker uses this dependency information to locate, and load, the associated objects. These dependencies are processed in the same order as the dependencies were referenced during the link-edit of the executable. Once all the dynamic executables dependencies are loaded, each dependency is inspected, in the order the dependency is loaded, to locate any additional dependencies. This process continues until all dependencies are located and loaded. This technique results in a breadth-first ordering of all dependencies.
2009/1/26
30
The Solaris runtime linker looks in two default locations for dependencies /lib and /usr/lib. The dependencies of a dynamic executable or shared object can be displayed using ldd. For example, the file /usr/bin/cat has the following dependencies: $ ldd /usr/bin/cat
libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2
The dependencies recorded in an object can be inspected using dump. Use this command to display the files .dynamic section, and look for entries that have a NEEDED tag.
$ dump -Lvp prog prog: [INDEX] Tag Value [1] NEEDED libfoo.so.1 [2] NEEDED libc.so.1 [3] RUNPATH /home/me/lib:/home/you/lib .........
2009/1/26
31
The dynamic segment (pointed to by the program header) in the ELF file contains a pointer to the file's string table (DT_STRTAB) as well as to the DT_NEEDED entries, each of which contains the offset in the string table for the name of a required library. The dynamic linker creates a scope list for the executable, consisting of libraries to be loaded. For each of the entries in the scope list , the linker searches for the file containing the library. Once the file is found, the linker reads the ELF Header to find the program header, which points to the dynamic segment . The linker maps the library to the process address space. From the dynamic segment, it adds the library's symbol table to the chain of symbol tables - and if the libraries has further dependencies, it adds those libraries to the list to be loaded and the process is continued. For clarification, note that in fact it actually creates a struct link_map for each of the library and adds it into a global linked list.
32
2009/1/26
typedef struct{
Elf32_Word st_name; Elf32_Addr st_value; Elf32_Word st_size; unsignedchar st_info; unsignedchar st_other; Elf32_Half st_shndx;
}Elf32_Sym;
2009/1/26
33
For dynamic linking, the Dynamic linker primarily uses two processor-specific tables, the Global Offset Table (GOT) and the Procedure Linkage Table (PLT). Dynamic linkers support PIC Code through the GOT in each shared library. The GOT contains absolute addresses to all of the static data referenced in the program. Both the executables that use the shared libraries and the shared library itself has a PLT. Similar to how the GOT redirects any position-independent address calculations to absolute locations, the PLT redirects positionindependent function calls to absolute locations.
2009/1/26
34
DT_NEEDED: This element holds the string table offset of a null-terminated string, giving the name of a needed library. The offset is an index into the table recorded in the DT_STRTAB entry. DT_HASH: This element holds the address of the symbol hash table which refers to the symbol table referenced by the DT_SYMTAB element. DT_STRTAB: This element holds the address of the string table. DT_SYMTAB: This element holds the address of the symbol table.
2009/1/26
35
2. Relocation Processing
After the runtime linker has loaded all the dependencies required by an application, the linker processes each object and performs all necessary relocations. Relocation is the process of connecting symbolic references with symbolic definitions. For example, when a program calls a function, the associated call instruction must transfer control to the proper destination address at execution. Relocatable files must have information that describes how to modify their section contents. This information allows executable and shared object files to hold the right information for a processs program image.
2009/1/26
36
The LD_BIND_NOW variable determines the dynamic linking behavior. If its set, the dynamic linker evaluates the PLT entries, which is all entries of type R_386_JMP_SLOT, at the load time itself. Otherwise, the dynamic linker does lazy linking of procedure addresses and hence the addresses are not bound unless the routines are called.
2009/1/26
37
Under delayed function binding or lazy loading model, any dependencies that are labeled for lazy loading are loaded only when explicitly referenced. By taking advantage of the lazy binding of a function call, the loading of a dependency is delayed until the function is first referenced. As a result, objects that are never referenced are never loaded. As a practical example (.dynamic), shows libdebug.so.1 is marked for lazy loading. The symbol information section
(.SUNW_syminfo), shows the symbol reference that triggers libdebug.so.1 loading. $ cc -o prog prog.c -L. -zlazyload -ldebug -znolazyload -lelf -R$ORIGIN $ elfdump -d prog Dynamic Section: .dynamic index tag value [0] POSFLAG_1 0x1 [ LAZY ] [1] NEEDED 0x123libdebug.so.1 [2] NEEDED 0x131 libelf.so.1 [3] NEEDED 0x13d libc.so.1
2009/1/26
38
2009/1/26
39
2009/1/26
40
sh_name: ".strtab" sh_type: SHT_STRTAB sh_addr: 0 (to indicate it is not part of the image)
2009/1/26
41
1.
Debugging Sections ARM Executable ELF supports three types of debugging information held in debugging Sections. ASD debugging tables
These provide backwards compatibility with ARM's Symbolic Debugger. ASD debugging information is stored in a single Section in the executable named .asd.
2. 3.
2009/1/26
42