diff dynload/README.txt @ 0:3e629dc19168

initial from svn dyncall-1745
author Daniel Adler
date Thu, 19 Mar 2015 22:24:28 +0100
parents
children
line wrap: on
line diff
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/dynload/README.txt	Thu Mar 19 22:24:28 2015 +0100
@@ -0,0 +1,113 @@
+dynload / abstraction to run-time shared library services:
+
+- loading/unloading into the current process
+- symbol lookup
+- enumerating symbol tables
+- elf: support for DT_GNU_HASH
+
+
+Todo:
+- a.out format
+- support for different kind of symbols
+  (exports,imports,sections,constants...)
+
+Notes on windows pe format:
+
+File Extension: dll
+
+Implementation:
+
+1. Access to internals
+   The handle returned by LoadLibrary() is a pointer to the PE header 
+   (which is a DOS header).
+
+
+Notes on elf:
+
+File Extension: so
+Variants: Two core classes are defined Elf 32- and 64-bit. 
+Only one model is compiled in the library (the current run-time format).
+
+Dynamic symbol table:
+
+Symbol table layout:
+1. Index 0 in any symbol table is used to represent undefined symbols.
+As such, the first entry in a symbol table (index 0) is always completely
+zeroed (type STT_NOTYPE), and is not used.
+
+2. If the file contains any local symbols, the second entry (index 1)
+the symbol table will be a STT_FILE symbol giving the name of the file.
+
+3. Section symbols.
+
+4. Register symbols.
+
+5. Global symbols that have been reduced to local scope via a mapfile.
+
+6. For each input file that supplied local symbols, a STT_FILE symbol
+   giving the name of the input file is put in the symbol table, 
+   followed by the symbols in question.
+
+7. The global symbols immediately follow the local symbols in the
+   symbol table. Local and global symbols are always kept separate
+   in this manner, and cannot be mixed together.
+
+
+Dynamic symbol table handling seem to be different among platforms.
+Due to System V ABI, one get access to the dynamic symbol table through
+the DT_HASH entry in "DYNAMIC" Program Header.
+
+It does not work on x86 on a x86_64 linux 2.6 machine.
+
+A closer look to the binaries in /usr/lib32 revealed, there are differences:
+
+differences
+ - elf32 has 21 sections
+ - elf64 has (21 + 2) sections
+     ".hash"
+     ".eh_frame_hdr"
+ -       elf64 has  ".rela.*" 
+   while elf32 has  ".rel.*"
+ 
+in common:
+ - both have a ".gnu.hash" section
+
+
+the ".gnu.hash" 
+
+
+Idea: "GNU hash" method ([3])
+
+
+Symbol Versioning:
+
+
+
+OS supported prelinking:
+
+linux has prelink
+irix has quickstart
+solaris has crle
+
+sparc uses STT_REGISTER:
+  STT_REGISTER is
+    The Sparc architecture has a concept known as a "register symbol". These
+    symbols are used to validate symbol/register usage, and can also be
+    used to initialize global registers. Other architectures don't use these.
+
+
+
+
+
+
+
+References:
+[1] Levin, R. John: Linkers & Loader
+[2] System V ABI
+[3] The cost of elf symbol hashing: http://blogs.sun.com/ali/entry/the_cost_of_elf_symbol 
+[4] GNU Hash ELF Section: http://blogs.sun.com/ali/entry/gnu_hash_elf_sections
+[5] http://refspecs.freestandards.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/symversion.html
+[6] elf: http://greek0.net/elf.html
+[7] System V ABI Application Binary Interface - Draft 17 - December 2003 (SCO) : 
+    http://sco.com/developers/gabi/latest/contents.html 
+