added new hierarchy

6 files changed, 260 insertions, 0 deletions

diff --git a/src/development/README.md b/src/development/README.md
new file mode 100644
index 0000000..459110d
--- /dev/null
+++ b/src/development/README.md
@@ -0,0 +1 @@
+# Development
diff --git a/src/development/c++.md b/src/development/c++.md
new file mode 100644
index 0000000..d9fbbda
--- /dev/null
+++ b/src/development/c++.md
@@ -0,0 +1,12 @@
+# c++
+
+## Type deduction
+
+Force compile error to see what `auto` is deduced to.
+```cpp
+auto foo = bar();
+
+// force compile error
+typename decltype(foo)::_;
+```
+
diff --git a/src/development/c++filt.md b/src/development/c++filt.md
new file mode 100644
index 0000000..2592ba9
--- /dev/null
+++ b/src/development/c++filt.md
@@ -0,0 +1,12 @@
+# c++filt(1)
+
+## Demangle symbol
+```markdown
+  c++-filt <symbol_str>
+```
+
+## Demangle stream
+For example dynamic symbol table:
+```markdown
+  readelf -W --dyn-syms <elf> | c++filt
+```
diff --git a/src/development/gcc.md b/src/development/gcc.md
new file mode 100644
index 0000000..1381242
--- /dev/null
+++ b/src/development/gcc.md
@@ -0,0 +1,58 @@
+# gcc(1)
+
+## CLI
+
+### Preprocessing
+While debugging can be helpful to just pre-process files.
+
+```bash
+gcc -E [-dM] ...
+```
+- `-E` run only preprocessor
+- `-dM` list only `#define` statements
+
+## [Builtins][builtins]
+
+### `__builtin_expect(expr, cond)`
+Give the compiler a hint which branch is hot, so it can lay out the code
+accordingly to reduce number of jump instructions.
+See on [compiler explorer](https://godbolt.org/z/MbTHAP).
+
+```bash
+echo "
+extern void foo();
+extern void bar();
+void run0(int x) {
+  if (__builtin_expect(x,0)) { foo(); }
+  else { bar(); }
+}
+void run1(int x) {
+  if (__builtin_expect(x,1)) { foo(); }
+  else { bar(); }
+}
+" | gcc -O2 -S -masm=intel -o /dev/stdout -xc -
+```
+
+Will generate something similar to the following.
+- `run0`: `bar` is on the path without branch
+- `run1`: `foo` is on the path without branch
+```c
+run0:
+        test    edi, edi
+        jne     .L4
+        xor     eax, eax
+        jmp     bar
+.L4:
+        xor     eax, eax
+        jmp     foo
+run1:
+        test    edi, edi
+        je      .L6
+        xor     eax, eax
+        jmp     foo
+.L6:
+        xor     eax, eax
+        jmp     bar
+```
+
+[builtins]: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
diff --git a/src/development/glibc.md b/src/development/glibc.md
new file mode 100644
index 0000000..2b2ab34
--- /dev/null
+++ b/src/development/glibc.md
@@ -0,0 +1,47 @@
+# glibc
+
+## malloc tracer [`mtrace(3)`][mtrace]
+Trace memory allocation and de-allocation to detect memory leaks.
+Need to call `mtrace(3)` to install the tracing hooks.
+
+If we can't modify the binary to call `mtrace` we can create a small shared
+library and pre-load it.
+```c
+// libmtrace.c
+#include <mcheck.h>
+__attribute__((constructor))  static void init_mtrace() { mtrace(); }
+```
+
+Compile as:
+```bash
+gcc -shared -fPIC -o libmtrace.so libmtrace.c
+```
+
+To generate the trace file run:
+```bash
+export MALLOC_TRACE=<file>
+LD_PRELOAD=./libmtrace.so <binary>
+```
+**Note**: If `MALLOC_TRACE` is not set `mtrace` won't install tracing hooks.
+
+To get the results of the trace file:
+```bash
+mtrace <binary> $MALLOC_TRACE
+```
+
+## malloc check [`mallopt(3)`][mallopt]
+Configure action when glibc detects memory error.
+
+```bash
+export MALLOC_CHECK_=<N>
+```
+
+Useful values:
+```markdown
+1   print detailed error & continue
+3   print detailed error + stack trace + memory mappings & abort
+7   print simple error message + stack trace + memory mappings & abort
+```
+
+[mtrace]: http://man7.org/linux/man-pages/man3/mtrace.3.html
+[mallopt]: http://man7.org/linux/man-pages/man3/mallopt.3.html
diff --git a/src/development/ld.so.md b/src/development/ld.so.md
new file mode 100644
index 0000000..311d1be
--- /dev/null
+++ b/src/development/ld.so.md
@@ -0,0 +1,130 @@
+# ld.so(8)
+
+## Environment Variables
+```console
+  LD_PRELOAD=<l_so>       colon separated list of libso's to be pre loaded
+  LD_DEBUG=<opts>         comma separated list of debug options
+          =help           list available options
+          =libs           show library search path
+          =files          processing of input files
+          =symbols        show search path for symbol lookup
+          =bindings       show against which definition a symbol is bound
+```
+
+## LD_PRELOAD: Initialization Order and Link Map
+Libraries specified in `LD_PRELOAD` are loaded from `left-to-right` but
+initialized from `right-to-left`.
+
+```markdown
+  > ldd ./main
+    >> libc.so.6 => /usr/lib/libc.so.6
+
+  > LD_PRELOAD=liba.so:libb.so ./main
+             -->
+      preloaded in this order
+             <--
+      initialized in this order
+```
+
+The preload order determines:
+- the order libraries are inserted into the `link map`
+- the initialization order for libraries
+
+For the example listed above the resulting `link map` will look like the
+following:
+
+```makrdown
+  +------+    +------+    +------+    +------+
+  | main | -> | liba | -> | libb | -> | libc |
+  +------+    +------+    +------+    +------+
+```
+
+This can be seen when running with `LD_DEBUG=files`:
+
+```makrdown
+  > LD_DEBUG=files LD_PRELOAD=liba.so:libb.so ./main
+    # load order (-> determines link map)
+    >> file=liba.so [0];  generating link map
+    >> file=libb.so [0];  generating link map
+    >> file=libc.so.6 [0];  generating link map
+
+    # init order
+    >> calling init: /usr/lib/libc.so.6
+    >> calling init: <path>/libb.so
+    >> calling init: <path>/liba.so
+    >> initialize program: ./main
+```
+
+To verify the `link map` order we let `ld.so` resolve the `memcpy(3)` libc
+symbol (used in _main_) dynamically, while enabling `LD_DEBUG=symbols,bindings`
+to see the resolving in action.
+
+```makrdown
+  > LD_DEBUG=symbols,bindings LD_PRELOAD=liba.so:libb.so ./main
+    >> symbol=memcpy;  lookup in file=./main [0]
+    >> symbol=memcpy;  lookup in file=<path>/liba.so [0]
+    >> symbol=memcpy;  lookup in file=<path>/libb.so [0]
+    >> symbol=memcpy;  lookup in file=/usr/lib/libc.so.6 [0]
+    >> binding file ./main [0] to /usr/lib/libc.so.6 [0]: normal symbol `memcpy' [GLIBC_2.14]
+```
+
+## Dynamic Linking (x86_64)
+Dynamic linking basically works via one indirect jump. It uses a combination of
+function trampolines (`.plt` section) and a function pointer table (`.got.plt`
+section).
+On the first call the trampoline sets up some metadata and then jumps to the
+`ld.so` runtime resolve function, which in turn patches the table with the
+correct function pointer.
+```makrdown
+  .plt ....... procedure linkage table, contains function trampolines, usually
+               located in code segment (rx permission)
+  .got.plt ... global offset table for .plt, holds the function pointer table
+```
+
+Using `radare2` we can analyze this in more detail:
+
+```makrdown
+  [0x00401040]> pd 4 @ section..got.plt
+              ;-- section..got.plt:
+              ;-- .got.plt:    ; [22] -rw- section size 32 named .got.plt
+              ;-- _GLOBAL_OFFSET_TABLE_:
+         [0]  0x00404000      .qword 0x0000000000403e10 ; section..dynamic
+         [1]  0x00404008      .qword 0x0000000000000000
+              ; CODE XREF from section..plt @ +0x6
+         [2]  0x00404010      .qword 0x0000000000000000
+              ;-- reloc.puts:
+              ; CODE XREF from sym.imp.puts @ 0x401030
+         [3]  0x00404018      .qword 0x0000000000401036 ; RELOC 64 puts
+
+  [0x00401040]> pd 6 @ section..plt
+              ;-- section..plt:
+              ;-- .plt:       ; [12] -r-x section size 32 named .plt
+          ┌─> 0x00401020      ff35e22f0000   push qword [0x00404008]
+          ╎   0x00401026      ff25e42f0000   jmp qword [0x00404010]
+          ╎   0x0040102c      0f1f4000       nop dword [rax]
+  ┌ 6: int sym.imp.puts (const char *s);
+  └       ╎   0x00401030      ff25e22f0000   jmp qword [reloc.puts]
+          ╎   0x00401036      6800000000     push 0
+          └─< 0x0040103b      e9e0ffffff     jmp sym..plt
+```
+
+- At address `0x00401030` in the `.plt` section we see the indirect jump for
+  `puts` using the function pointer in `_GLOBAL_OFFSET_TABLE_[3] (GOT)`.
+- `GOT[3]` initially points to instruction after the `puts` trampoline
+  `0x00401036`.
+- This pushes the relocation index `0` and then jumps to the first trampoline
+  `0x00401020`.
+- The first trampoline jumps to `GOT[2]` which will be filled at program
+  startup by the `ld.so` with its resolve function.
+- The `ld.so` resolve function fixes the relocation referenced by the
+  relocation index pushed by the `puts` trampoline.
+- The relocation entry at index `0` tells the resolve function which symbol to
+  search for and where to put the function pointer:
+  ```makrdown
+    > readelf -r <main>
+      >> Relocation section '.rela.plt' at offset 0x4b8 contains 1 entry:
+      >>   Offset          Info           Type           Sym. Value    Sym. Name + Addend
+      >> 000000404018  000200000007 R_X86_64_JUMP_SLO 0000000000000000 puts@GLIBC_2.2.5 + 0
+   ```
+  As we can see the offset from relocation at index `0` points to `GOT[3]`.
+