ld.so: remove leading whitespaces

1 files changed, 62 insertions, 62 deletions

diff --git a/src/development/ld.so.md b/src/development/ld.so.md
index 062bac6..67ff6e9 100644
--- a/src/development/ld.so.md
+++ b/src/development/ld.so.md
@@ -2,13 +2,13 @@
 
 ## 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=<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_LIBRARY_PATH and dlopen(3)
@@ -31,14 +31,14 @@ 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
+> 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:
@@ -57,17 +57,17 @@ following:
 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
+> 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
@@ -75,12 +75,12 @@ 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]
+> 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)
@@ -91,36 +91,36 @@ 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
+.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
+[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
@@ -136,10 +136,10 @@ Using `radare2` we can analyze this in more detail:
 - 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
-   ```
+  > 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]`.