Mercurial > pub > dyncall > dyncall

comparison dynload/README.txt @ 0:3e629dc19168

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
initial from svn dyncall-1745
author Daniel Adler
date Thu, 19 Mar 2015 22:24:28 +0100
parents
children
comparison
equal deleted inserted replaced
-1:000000000000 0:3e629dc19168
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