Something About Dynamic Linking

Something About
Dynamic Linking
Kai

ELFmemory
ELF header
typedef struct
{
unsigned char e_ident[EI_NIDENT];
Elf32_Half e_type;
Elf32_Half e_machine;
Elf32_Word e_version;
Elf32_Addr e_entry;
Elf32_Off e_phoff; /* offset of Program Header table*/
Elf32_Off e_shoff;
Elf32_Word e_flags;
Elf32_Half e_ehsize;
Elf32_Half e_phentsize; /* the size of each entry */
Elf32_Half e_phnum; /* the number of entries */
Elf32_Half e_shentsize;
Elf32_Half e_shnum;
Elf32_Half e_shstrndx; 
} Elf32_Ehdr;

ELFmemory
ELF header
typedef struct
{
unsigned char e_ident[EI_NIDENT];
Elf32_Half e_type;
Elf32_Half e_machine;
Elf32_Word e_version;
Elf32_Addr e_entry;
Elf32_Off e_phoff; /* offset of Program Header table*/
Elf32_Off e_shoff;
Elf32_Word e_flags;
Elf32_Half e_ehsize;
Elf32_Half e_phentsize; /* the size of each entry */
Elf32_Half e_phnum; /* the number of entries */
Elf32_Half e_shentsize;
Elf32_Half e_shnum;
Elf32_Half e_shstrndx; 
} Elf32_Ehdr;
ELF Program
Header table

ELFmemory
ELF header
ELF Program
Header table

ELFmemory
ELF header
ELF Program
Header table
typedef struct
{
Elf32_Word p_type; /* PT_LOAD */
Elf32_Off p_offset;
Elf32_Addr p_vaddr;
Elf32_Addr p_paddr;
Elf32_Word p_filesz;
Elf32_Word p_memsz;
Elf32_Word p_flags;
Elf32_Word p_align; 
} Elf32_Phdr;

ELFmemory
ELF header
ELF Program
Header table
typedef struct
{
Elf32_Off p_offset;
Elf32_Addr p_vaddr;
Elf32_Addr p_paddr;
Elf32_Word p_memsz;
Elf32_Word p_flags;
} Elf32_Phdr;
segment

ELFmemory
ELF header
ELF Program
Header table
typedef struct
{
Elf32_Off p_offset;
Elf32_Addr p_vaddr;
Elf32_Addr p_paddr;
Elf32_Word p_memsz;
Elf32_Word p_flags;
} Elf32_Phdr;
segment
segment in
memory

ELFmemory
ELF header
ELF Program
Header table
typedef struct
{
Elf32_Word p_type; /* PT_INTERP */
Elf32_Off p_offset;
Elf32_Addr p_vaddr;
Elf32_Addr p_paddr;
Elf32_Word p_memsz;
Elf32_Word p_flags;
} Elf32_Phdr;
/lib/ld-linux.so.2
segment in
memory
segment

ELFmemory
ELF header
ELF Program
Header table
typedef struct
{
Elf32_Off p_offset;
Elf32_Addr p_vaddr;
Elf32_Addr p_paddr;
Elf32_Word p_memsz;
Elf32_Word p_flags;
} Elf32_Phdr;
/lib/ld-linux.so.2
segment in
memory
dynamic
linker
segment

ELFmemory
ELF header
ELF Program
Header table
typedef struct
{
Elf32_Off p_offset;
Elf32_Addr p_vaddr;
Elf32_Addr p_paddr;
Elf32_Word p_memsz;
Elf32_Word p_flags;
} Elf32_Phdr;
/lib/ld-linux.so.2
segment in
memory
dynamic
linker
auxiliary
vector
stack
segment

ELFmemory
ELF header
ELF Program
Header table
typedef struct
{
Elf32_Off p_offset;
Elf32_Addr p_vaddr;
Elf32_Addr p_paddr;
Elf32_Word p_memsz;
Elf32_Word p_flags;
} Elf32_Phdr;
/lib/ld-linux.so.2
segment in
memory
dynamic
linker
auxiliary
vector
stack
entry
segment

Dynamic Linker
• Determine and load dependencies
• Relocate the application and all dependencies
• Initialise the application and dependencies in the
correct order

Types of Relocation
• Relative relocation
• Location which are known to be in the own object
• Not associated with a specific symbol
• Named relocation
• Based on symbols
• The reference of the definition is generally in a
different object than the definition

Symbol Lookup
• Traditional ELF Hash Table Handling
• GNU-style Hash Table Handling

1. Determine the hash value for the relocation name
2. For the object in the lookup scope,
A. Get the hash bucket using the hash value
B. Get the name offset of the symbol
C. Compare the symbol name with the relocation name
D. If the names match, we found the deﬁnition
E. If the names do not match, retry with next element in the
bucket
F. If there is no other element in the bucket, try next object.
3. If there is no other object in the lookup scope, the lookup failed
Traditional ELF Hash Table Handling

Traditional ELF Hash Table Handling
• If the scope contains more than one definition of the same
symbol, the algorithm simply picks up the first definition it finds.
• Use LD_PRELOAD to replace implementation
• LD_PRELOAD=./libfoo.so ./a.out
• The performance of each lookup depends on
• The length of the hash chains
• the number of symbols
• the choice of the hash table size
• The number of objects

/* sum.c */
#include <stdio.h>
int sum(int a, int b)
{
printf("sum is calledn");
return a + b;
}
/* sum_v2.c */
#include <stdio.h>
int base = 100;
int sum(int a, int b)
{
printf("sum (with base %d) is calledn", base);
return base + a + b;
}

LD_DEBUG=symbols LD_DEBUG_OUTPUT=debug.log LD_PRELOAD=./libsumv2.so ./a.out
LD_DEBUG=symbols LD_DEBUG_OUTPUT=debug.log ./a.out

1. Determine the hash value for the relocation name
2. For the object in the lookup scope,
A. Determine whether an entry with the given hash value is
presented (2-bit Bloom filter). If the filter indicates there is
no such definition, the next object is searched.
B. Determine the hash bucket
C. Get the entry from the chain array. Compare the value with
the hash value of the symbol. Ignore bit 0.
D. If the hash value matches, get the name offset.
E. Compare the symbol name with the relocation name
F. If the names match, we found the definition
G. If the names do not match and the value loaded from the
hash bucket does not have bit 0 set, retry with next element
in the bucket array
H. If bit 0 is set, there is no further entry in the hash chain, try
next object.
3. If there is no other object in the lookup scope, the lookup failed
GNU-style Hash Table Handling

Lookup Scope
• An ordered list of most loaded object
• global lookup scope
• executable
• all its dependencies in DT_NEEDED (added in breadth-ﬁrst order)
• DT_SYMBOLIC: the object with the reference is added in front of the global lookup scope
• Only the object itself is added in front, not its dependencies
• local lookup scope
• DSO loaded dynamic using dlopen
• RTDL_GLOBAL: the loaded object and all the dependencies are added to the global
scope
• RTDL_DEEPBIND: search local lookup scope before global lookup scope

LD_DEBUG=symbols LD_PRELOAD=./libfoo_v2.so ./test_foo_sym
LD_DEBUG=symbols LD_PRELOAD=./libfoo_v2.so ./test_foo

/* foo.c */
void foo(void)
{
printf("foo in libfoo.son");
}
void libfoo(void)
{
printf("libfoo calls ");
foo();
}
/* foo_dyn.c */
void foo(void)
{
printf("foo in libfoo_dyn.son");
}
void libfoo(void)
{
printf("libfoo, dynamically loaded, calls ");
foo();
}

#include <stdio.h>
#include <dlfcn.h>
typedef void (*ptr)(void);
int main()
{
void *handle;
ptr foo_ptr;
libfoo();
handle = dlopen("libfoo_dyn.so", RTLD_LAZY);
foo_ptr = dlsym(handle, "libfoo");
foo_ptr();
dlclose(handle);
return 0;
}

#include <stdio.h>
#include <dlfcn.h>
int main()
{
void *handle;
ptr foo_ptr;
libfoo();
handle = dlopen("libfoo_dyn.so", RTLD_LAZY | RTLD_DEEPBIND);
foo_ptr = dlsym(handle, "libfoo");
foo_ptr();
dlclose(handle);
return 0;
}

/* foo_dyn.c */
void foo(void)
{
printf("foo in libfoon");
}
void bar(void)
{
printf("bar in libfoon");
}
void libfoo(void)
{
printf("libfoo, dynamically loaded, calls ");
foo();
}

/* bar_dyn.c */
void bar(void)
{
printf("bar in libbarn");
}
void libbar(void)
{
printf("libbar, dynamically loaded, calls ");
bar();
}

RTLD_GLOBAL
dlopen(“libfoo_dyn.so”, RTLD_LAZY | RTLD_GLOBAL)

GOT & PLT
movl $foo, %edi
call bar
movl $0, %eax
movq foo@GOTPCREL(%rip), %rax
movq %rax, %rdi
call bar@PLT
extern void foo(void);
extern void bar(ptr fn);
int libbar(void)
{
bar(foo);
return 0;
}
PIC
non-PIC

GOT & PLT
Disassembly of section .plt:
<_init+0x20>:
pushq 0x199a(%rip)
jmpq *0x199c(%rip)
nop
nop
nop
nop
. . .
<bar@plt>:
jmpq *0x198a(%rip)
pushq $0x2
jmpq 650 <_init+0x20>
call bar@PLT # dl-trampoline.S
<_dl_runtime_resolve>:
. . .
<bar>:
. . .
0
GOT

GOT & PLT
<_init+0x20>:
pushq 0x199a(%rip)
jmpq *0x199c(%rip)
nop
nop
nop
nop
. . .
<bar@plt>:
jmpq *0x198a(%rip)
pushq $0x2
. . .
<bar>:
. . .
GOT
bar

GOT & PLT
<_init+0x20>:
pushq 0x199a(%rip)
jmpq *0x199c(%rip)
nop
nop
nop
nop
. . .
<bar@plt>:
jmpq *0x198a(%rip)
pushq $0x2
. . .
<bar>:
. . .
GOT

Data Definitions
• Common
• There can be more than one definition and they all get unified into one location.
• Unintialized
• It allows the linker to find multiple definitions and flag them as errors.
• Variables initialised with zero
• __attribute__ ((nocommon))
• -fno-common
• Initialised
• The initialisation value is stored in the file.
• It is always preferable to add variables as uninitialised or initialised with zero as
opposed to as initialised with a value other than zero.
• save disk space and eventually improve startup time.

Visibility
• default
• The symbol is exported and can be interposed.
• hidden
• while static restricts the visibility of a symbol to the file it is defined in, the hidden
attribute limits the visibility to the DSO the definition ends up in.
• the linker will not add hidden symbols to the dynamic symbol table.
• internal
• internal visibility is like hidden visibility, but with additional processor specific semantics.
• protected
• references to symbols defined in the same object are always satisfied locally, but the
symbols are still available outside the DSO.

Export Control
• Use static
• Define global visibility
• -fvisibility=hidden
• Define per-symbol visibility
• __attribute__ ((visibility (“hidden”)))
• #pragma GCC visibility push(hidden)
• Export Map
• -Wl,—version-script=symbol.map
• The linker is used only after the compiler already did its work and the
once generated code cannot be optimised significantly.

int last;
int next(void)
{
return ++last;
}
int foo(int scale)
{
return next() << scale; 
}
Use Static
static
static int last;
static int next(void)
{
return ++last;
}
int foo(int scale)
{
}

Deﬁne Visibility
gcc -fPIC -fvisibility=hidden -S test.c
int last;
int next(void)
{
return ++last;
}
int __attribute__ ((visibility (“default”)))
foo(int scale)
{
}

Export Map
{
global: foo;
local: *;
};

Avoid Using Exported Symbols
• In some situations it might not be desirable to avoid exporting a symbol
but at the same time all local references should use the local deﬁnition.
• Wrapper functions
• Using aliases
• __attribute__ ((alias (“symbol”), visibility (“hidden”)))
• It is mandatory to create alias only of non-static functions and
variables.
• DT_SYMBOLIC
• all interfaces are affected
• the compiler does not get told about the use of local symbols
• lookup scope is changed

Wrapper Functions
static int last;
static int next_int (void) {
return ++last;
}
int next (void) { // wrapper function
return next_int ();
}
int index (int scale) {
return next_int () << scale;
}

Alias
int last;
extern __typeof (last) last_int // used in internal
__attribute ((alias (“last"), visibility (“hidden")));
int next (void) {
return ++last_int;
}
extern __typeof (next) next_int // used in internal
__attribute ((alias (“next"), visibility (“hidden")));
int index (int scale) {
return next_int () << scale;
}

Pointers v.s. Arrays
// the use of a variable is unnecessary.
char *str = “some string”;
// Here “str” is a name for a sequence of bytes.
// save one pointer variable in the non-sharable data segment
// save one relative relocation
char str[] = “some string”;
// compiler is able to move the string in read-only memory
const char str[] = “some string”;

Pointers v.s. Arrays
const char const *str = “some string”;
const char []str = “some string”;

Arrays of Data Pointers
// The total cost for this code is three words of data
// in writable memory and three relocations modifying
// this data in addition to the memory for the strings
// themselves.
static const char *msgs[] = {
[ERR1] = "message for err1",
[ERR3] = "message for err3"
};
const char *errstr (int nr) {
return msgs[nr];
}
// If the strings have different lengths it would mean
// wasting quite a bit of memory.
static const char msgs[][17] = {
[ERR3] = "message for err3"
};

Arrays of Data Pointers
// The cost of this code include three size_t words in
// read-only memory in addition to the memory for the strings.
static const char msgstr[] =
"message for err10"
"message for err20"
"message for err3”;
static const size_t msgidx[] = {
0,
sizeof ("message for err1"),
sizeof ("message for err1")
+ sizeof ("message for err2")
};
const char *errstr (int nr) {
return msgstr + msgidx[nr];
}

Security
• A changed GOT value might redirect a call to a function to an
arbitrary other place.
• -z relro linker option
• The linker is instructed to move the sections onto separate
memory page and emit a new program header entry
PT_GNU_RELRO.
• At runtime the dynamic linker can remove the write access to
those pages after it is done.
• -z now linker option
• Disable all lazy relocation at the expense of increased startup
costs.

Inter-Object File Relations
• By default the dynamic linker only looks into a few
directories to ﬁnd DSOs.
• /lib
• /usr/lib
• Directories in /etc/ld.so.conf
• LD_LIBRARY_PATH environment variable
• rpath settings

Run Path
• Programmers could decide the path directly.
• The dynamic linker will use the value of the run path string when searching for dependencies of
the object.
• DT_RPATH (deprecated)
• Used before LD_LIBRARY_PATH
• It does not allow the user to overwrite the value.
• -rpath or -R linker option
• DT_RUNPATH
• Used after LD_LIBRARY_PATH
• --enable-new-dtags
• Empty path represents the current working directory.
• Dynamic string token
• $ORIGIN, $LIB, $PLATFORM

Reference
• How to Write Shared Libraries - Ulrich Drepper
• https://software.intel.com/sites/default/ﬁles/m/a/1/
e/dsohowto.pdf
• ELF Symbol Versioning
• https://www.akkadia.org/drepper/symbol-
versioning

Something About Dynamic Linking

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Something About Dynamic Linking

Similar to Something About Dynamic Linking (20)

More from Wang Hsiangkai

More from Wang Hsiangkai (8)

Recently uploaded

Recently uploaded (20)

Something About Dynamic Linking