explain/rtld.md
... ...
@@ -4,7 +4,7 @@
4 4
Dynamic linking is the process of loading code and data from shared libraries.
5 5
For an overview, see [this
6 6
](https://0x00sec.org/t/linux-internals-dynamic-linking-wizardry/1082) and [
7
-this page](https://0x00sec.org/t/linux-internals-the-art-of-symbol-resolution/1488).
7
+this page](https://0x00sec.org/t/linux-internals-the-art-of-symbol-resolution/1488), or [this talk by Matt Godbolt](https://www.youtube.com/watch?v=dOfucXtyEsU).
8 8
For a series of very in-depth articles, see [this page
9 9
](https://www.airs.com/blog/archives/38) etc.
10 10
... ...
@@ -36,7 +36,7 @@ symbols, and performs the required relocations to glue all code together.
36 36
However, there's one entry, `DT_DEBUG`, which isn't documented (the docs say
37 37
"for debugging purposes"). What it actually does, is that the dynamic linker
38 38
places a pointer to its `r_debug` struct in the value field. This behavior
39
-is mostly portable (as in, it works on at least glibc, musl and FreeBSD). If
39
+is mostly portable (as in, it works on at least glibc, musl, bionic and FreeBSD). If
40 40
you look at your system's `link.h` file (eg. in `/usr/include`), you can see
41 41
the contents of this struct. The second field is a pointer to the root
42 42
`link_map`. More about this one later.
... ...
@@ -56,8 +56,9 @@ It's a linked list containing information of every ELF file loaded by the rtld.
56 56
`link_map` contains the path, base address and a pointer to its `PT_DYNAMIC`
57 57
phdr. We can use the latter to traverse all the symbol tables and figure out
58 58
what the address of every symbol is. This is what **bold** and **dnload** do,
59
-except they save a hash of every symbol name, instead of the symbol names
60
-themselves.
59
+except they save a hash of the names of the required symbols, instead of the
60
+symbol names themselves, computes the hashes of the symbol names from the
61
+`link_map`, and compare thise.
61 62
62 63
However, there are a few ways to save even more bytes:
63 64