|
0
|
1 dynload / abstraction to run-time shared library services:
|
|
|
2
|
|
|
3 - loading/unloading into the current process
|
|
|
4 - symbol lookup
|
|
|
5 - enumerating symbol tables
|
|
|
6 - elf: support for DT_GNU_HASH
|
|
|
7
|
|
|
8
|
|
|
9 Todo:
|
|
|
10 - a.out format
|
|
|
11 - support for different kind of symbols
|
|
|
12 (exports,imports,sections,constants...)
|
|
|
13
|
|
|
14 Notes on windows pe format:
|
|
|
15
|
|
|
16 File Extension: dll
|
|
|
17
|
|
|
18 Implementation:
|
|
|
19
|
|
|
20 1. Access to internals
|
|
|
21 The handle returned by LoadLibrary() is a pointer to the PE header
|
|
|
22 (which is a DOS header).
|
|
|
23
|
|
|
24
|
|
|
25 Notes on elf:
|
|
|
26
|
|
|
27 File Extension: so
|
|
|
28 Variants: Two core classes are defined Elf 32- and 64-bit.
|
|
|
29 Only one model is compiled in the library (the current run-time format).
|
|
|
30
|
|
|
31 Dynamic symbol table:
|
|
|
32
|
|
|
33 Symbol table layout:
|
|
|
34 1. Index 0 in any symbol table is used to represent undefined symbols.
|
|
|
35 As such, the first entry in a symbol table (index 0) is always completely
|
|
|
36 zeroed (type STT_NOTYPE), and is not used.
|
|
|
37
|
|
|
38 2. If the file contains any local symbols, the second entry (index 1)
|
|
|
39 the symbol table will be a STT_FILE symbol giving the name of the file.
|
|
|
40
|
|
|
41 3. Section symbols.
|
|
|
42
|
|
|
43 4. Register symbols.
|
|
|
44
|
|
|
45 5. Global symbols that have been reduced to local scope via a mapfile.
|
|
|
46
|
|
|
47 6. For each input file that supplied local symbols, a STT_FILE symbol
|
|
|
48 giving the name of the input file is put in the symbol table,
|
|
|
49 followed by the symbols in question.
|
|
|
50
|
|
|
51 7. The global symbols immediately follow the local symbols in the
|
|
|
52 symbol table. Local and global symbols are always kept separate
|
|
|
53 in this manner, and cannot be mixed together.
|
|
|
54
|
|
|
55
|
|
|
56 Dynamic symbol table handling seem to be different among platforms.
|
|
|
57 Due to System V ABI, one get access to the dynamic symbol table through
|
|
|
58 the DT_HASH entry in "DYNAMIC" Program Header.
|
|
|
59
|
|
|
60 It does not work on x86 on a x86_64 linux 2.6 machine.
|
|
|
61
|
|
|
62 A closer look to the binaries in /usr/lib32 revealed, there are differences:
|
|
|
63
|
|
|
64 differences
|
|
|
65 - elf32 has 21 sections
|
|
|
66 - elf64 has (21 + 2) sections
|
|
|
67 ".hash"
|
|
|
68 ".eh_frame_hdr"
|
|
|
69 - elf64 has ".rela.*"
|
|
|
70 while elf32 has ".rel.*"
|
|
|
71
|
|
|
72 in common:
|
|
|
73 - both have a ".gnu.hash" section
|
|
|
74
|
|
|
75
|
|
|
76 the ".gnu.hash"
|
|
|
77
|
|
|
78
|
|
|
79 Idea: "GNU hash" method ([3])
|
|
|
80
|
|
|
81
|
|
|
82 Symbol Versioning:
|
|
|
83
|
|
|
84
|
|
|
85
|
|
|
86 OS supported prelinking:
|
|
|
87
|
|
|
88 linux has prelink
|
|
|
89 irix has quickstart
|
|
|
90 solaris has crle
|
|
|
91
|
|
|
92 sparc uses STT_REGISTER:
|
|
|
93 STT_REGISTER is
|
|
|
94 The Sparc architecture has a concept known as a "register symbol". These
|
|
|
95 symbols are used to validate symbol/register usage, and can also be
|
|
|
96 used to initialize global registers. Other architectures don't use these.
|
|
|
97
|
|
|
98
|
|
|
99
|
|
|
100
|
|
|
101
|
|
|
102
|
|
|
103
|
|
|
104 References:
|
|
|
105 [1] Levin, R. John: Linkers & Loader
|
|
|
106 [2] System V ABI
|
|
|
107 [3] The cost of elf symbol hashing: http://blogs.sun.com/ali/entry/the_cost_of_elf_symbol
|
|
|
108 [4] GNU Hash ELF Section: http://blogs.sun.com/ali/entry/gnu_hash_elf_sections
|
|
|
109 [5] http://refspecs.freestandards.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/symversion.html
|
|
|
110 [6] elf: http://greek0.net/elf.html
|
|
|
111 [7] System V ABI Application Binary Interface - Draft 17 - December 2003 (SCO) :
|
|
|
112 http://sco.com/developers/gabi/latest/contents.html
|
|
|
113
|
