From 2a064a9d1bbb8de6ce489b685cce026eee167cd2 Mon Sep 17 00:00:00 2001 From: johannst Date: Tue, 17 Mar 2020 22:48:49 +0000 Subject: deploy: fb719f52b73920fb18c7f3080ebb1fc73300be49 --- print.html | 424 +++++++++++++++++++++++++++++++++++++------------------------ 1 file changed, 258 insertions(+), 166 deletions(-) (limited to 'print.html') diff --git a/print.html b/print.html index 461fa81..f688b69 100644 --- a/print.html +++ b/print.html @@ -83,7 +83,7 @@ @@ -151,16 +151,18 @@

ld.so(8)

-

Environment variables

+

Environment Variables

  LD_PRELOAD=<l_so>       colon separated list of libso's to be pre loaded
-  LD_DEBUG=<opts>         comman separated list of debug options
+  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 load & init order

+

LD_PRELOAD: Initialization Order and Link Map

+

Libraries specified in LD_PRELOAD are loaded from left-to-right but +initialized from right-to-left.

  > ldd ./main
     >> libc.so.6 => /usr/lib/libc.so.6
 
@@ -169,97 +171,106 @@
       preloaded in this order
              <--
       initialized in this order
-
-  - preload order determines the order libs are inserted into the link map
-
-  - resulting link map:
-      +------+    +------+    +------+    +------+
-      | main | -> | liba | -> | libb | -> | libc |
-      +------+    +------+    +------+    +------+
-
-  - see preload and init order in action
-    > 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
-
-  - see the symbol lookup in action and therefore the link map order
-    > 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) and a function pointer table
-    (.got.plt). 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.
-      .plt ....... contains function trampolines, usually located in code
-                   segment (rx permission)
-      .got.plt ... hold the function pointer table
-
-  - following r2 dump shows this
-      - [0x00401030] indirect jump for 'puts' using function pointer in
-        _GLOBAL_OFFSET_TABLE_[3]
-      - initially points to instruction behind 'puts' trampoline [0x00401036]
-      - this pushes relocation index and then jumps to the first trampoline
-        [0x00401020]
-      - the first trampoline jumps to _GLOBAL_OFFSET_TABLE_[2] which will be
-        filled at program startup by the ld.so with its resolve function
-      - the resolve function fixes the relocation referenced by the
-        relocation index pushed by the 'puts' trampoline
-      - the relocation entry tells the resolve function which symbol to
-        search for and where to put the function pointer
-          > 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
-          - offset points to _GLOBAL_OFFSET_TABLE_[3]
-
-      [0x00401040]> pd 4 @ section..got.plt
-                  ;-- section..got.plt:
-                  ;-- .got.plt:    ; [22] -rw- section size 32 named .got.plt
-                  ;-- _GLOBAL_OFFSET_TABLE_:
-                  0x00404000      .qword 0x0000000000403e10 ; section..dynamic ; obj._DYNAMIC
-                  0x00404008      .qword 0x0000000000000000
-                  ; CODE XREF from section..plt @ +0x6
-                  0x00404010      .qword 0x0000000000000000
-                  ;-- reloc.puts:
-                  ; CODE XREF from sym.imp.puts @ 0x401030
-                  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
+

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:

+
  +------+    +------+    +------+    +------+
+  | main | -> | liba | -> | libb | -> | libc |
+  +------+    +------+    +------+    +------+
+
+

This can be seen when running with LD_DEBUG=files:

+
  > 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.

+
  > 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.

+
  .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:

+
  [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: +
      > 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].
    • +

git(1)

-

Misc

+

staging

  git add -p [<file>] ............ partial staging (interactive)
-

remote

+

Remote

  git remote -v .................. list remotes verbose (with URLs)
   git remote show [-n] <remote> .. list info for <remote> (like remote HEAD,
                                    remote branches, tracking mapping)
-

branching

+

Branching

  git branch [-a] ................ list available branches; -a to include
                                    remote branches
   git branch -vv ................. list branch & annotate with head sha1 &
@@ -269,7 +280,7 @@
   git push -u origin <rbname> .... push branch to origin (or other remote), and
                                    setup <rbname> as tracking branch
-

resetting

+

Resetting

  git reset [opt] <ref|commit>
     opt:
       --mixed .................... resets index, but not working tree
@@ -281,25 +292,26 @@
   git reset --soft HEAD~1 ........ delete most recent commit but keep work
   git reset --hard HEAD~1 ........ delete most recent commit and delete work
-

tags

+

Tags

  git tag -a <tname> -m "descr" ........ creates an annotated tag (full object
                                          containing tagger, date, ...)
   git tag -l ........................... list available tags
   git checkout tag/<tname> ............. checkout specific tag
   git checkout tag/<tname> -b <bname> .. checkout specific tag in a new branch
-

diff

+

Diff

  git diff HEAD:<fname> origin/HEAD:<fname> ... diff files for different refs
   git diff -U$(wc -l <fname>) <fname> ......... shows complete file with diffs
                                                 instead of usual diff snippets
-

log

+

Log

  git log --oneline .... shows log in single line per commit -> alias for
                          '--pretty=oneline --abbrev-commit'
   git log --graph ...... text based graph of commit history
   git log --decorate ... decorate log with REFs
+  git log -p <file> .... show commit history + diffs for <file>
-

patching

+

Patching

  git format-patch <opt> <since>/<revision range>
     opt:
       -N ................... use [PATCH] instead [PATCH n/m] in subject when
@@ -323,7 +335,7 @@
   # generate single patch file from a certain commit/ref
   git format-patch <COMMIT/REF> --stdout > my-patch.patch
-

submodules

+

Submodules

  git submodule add <url> [<path>] .......... add new submodule to current project
   git clone --recursive <url> ............... clone project and recursively all
                                               submodules (same as using
@@ -337,18 +349,56 @@
                                               origin/HEAD or a branch specified
                                               for the submodule
-

inspection

+

Inspection

  git ls-tree [-r] <ref> .... show git tree for <ref>, -r to recursively ls sub-trees
   git show <obj> ............ show <obj>
   git cat-file -p <obj> ..... print content of <obj>
-

revision_range

+

Revision Specifier

  HEAD ........ last commit
   HEAD~1 ...... last commit-1
   HEAD~N ...... last commit-N (linear backwards when in tree structure, check
                 difference between HEAD^ and HEAD~)
   git rev-list --max-parents=0 HEAD ........... first commit
+

awk(1)

+
awk [opt] program [input]
+    -F <sepstr>        field separator string (can be regex)
+    program            awk program
+    input              file or stdin if not file given
+
+

Input processing

+

Input is processed in two stages:

+
    +
  1. Splitting input into a sequence of records. +By default split at newline character, but can be changed via the +builtin RS variable.
    2. +
  2. Splitting a record into fields. By default strings without whitespace, +but can be changed via the builtin variable FS or command line option +-F.
    3. +
+

Field are accessed as follows:

+
    +
  • $0 whole record
    • +
  • $1 field one
    • +
  • $2 field two
    • +
  • ...
    • +
+

Program

+

An awk program is composed of pairs of the form:

+
pattern { action }
+
+

The program is run against each record in the input stream. If a pattern +matches a record the corresponding action is executed and can access the +fields.

+
INPUT
+  |
+  v
+record ----> ∀ pattern matched
+  |                   |
+  v                   v
+fields ----> run associated action
+

gdb(1)

CLI

  gdb [opts] [prg [-c coredump | -p pid]]
@@ -415,6 +465,7 @@
           Create a catchpoint for <signal>.

User commands (macros)

+

Gdb allows to create & document user commands as follows:

  define <cmd>
     # cmds
   end
@@ -422,23 +473,29 @@
   document <cmd>
     # docu
   end
-
-  help user-defined             List user defined commands.
-  help <cmd>                    List documentation for command <cmd>.
+
+

To get all user commands or documentations one can use:

+
  help user-defined
+  help <cmd>

Hooks

-

Gdb allows to create two types of command hooks which will be either executed -before or after a certain command.

-
  define hook-<cmd>             Run commands defined in hook before
-    # cmds                      executing <cmd>.
+
Gdb allows to create two types of command hooks

+
    
+
  • hook- will be run before <cmd>
    • 
+
  • hookpost- will be run after <cmd>
    • 
+

+
  define hook-<cmd>
+    # cmds
   end
 
-  define hookpost-<cmd>         Run commands defined in hookpost after
-    # cmds                      executing <cmd>.
+  define hookpost-<cmd>
+    # cmds
   end
 

-
Flows

-
Catch SIGSEGV and execute commands on occurrence

+
Examples

+
Catch SIGSEGV and execute commands

+
This creates a catchpoint for the SIGSEGV signal and attached the command
+to it.

 
  catch signal SIGSEGV
   command
     bt
@@ -449,8 +506,9 @@ before or after a certain command.

 
  gdb --batch -ex 'thread 1' -ex 'bt' -p <pid>
 

 
Script gdb for automating debugging sessions

-
# run.gdb
-  set pagination off
+
To script gdb add commands into a file and pass it to gdb via -x.
+For example create run.gdb:

+
  set pagination off
 
   break mmap
   command
@@ -463,20 +521,21 @@ before or after a certain command.

   c
 

 
This script can be used as:

-
  gdb -p <pid> -x ./run.gdb  --batch &> run.log
+
  gdb --batch -x ./run.gdb -p <pid>
 

+
Know Bugs

 
Workaround command + finish bug

-
When using finish action inside a command block, actions after finish are
-not executed anymore. To workaround that bug one can create a wrapper function
-which calls finish.

+
When using finish inside a command block, commands after finish are not
+executed. To workaround that bug one can create a wrapper function which calls
+finish.

 
  define handler
-  bt
-  finish
-  info reg rax
+    bt
+    finish
+    info reg rax
   end
 
   command
-  handler
+    handler
   end
 

 
radare2(1)

@@ -563,7 +622,7 @@ which calls finish.

 
strace [opts] [prg]
   -f .......... follow child processes on fork(2)
   -p <pid> .... attach to running process
-  -s <size> ... max string size (default: 32)
+  -s <size> ... max string size, truncate of longer (default: 32)
   -e <expr> ... expression for trace filtering
   -o <file> ... log output into <file>
   -c .......... dump syscall statitics at the end
@@ -575,20 +634,20 @@ which calls finish.

   trace=signal ............... trace signal related syscalls
   signal ..................... trace signals delivered to the process
 

-
Examples

-
Trace 'open & socket syscalls for a running process + childs.

-
strace -f -p <pid> -e trace=open,socket
+
Examples

+
Trace open(2) & socket(2) syscalls for a running process + child processes:

+
strace -f -e trace=open,socket -p <pid>
 

-
Trace signals delivered to a running process.

-
strace -f -p <pid> -e signal
+
Trace signals delivered to a running process:

+
strace -f -e signal -p <pid>
 

 
lsof(8)

 
lsof
   -a ......... AND slection filters instead ORing (OR: default)
-  -p <pid> ... list open file descriptors for process
+  -p <pid> ... filter by <pid>
   +fg ........ show file flags for file descripros
   -n ......... don't convert network addr to hostnames
-  -P ......... don't convert network port to know service names
+  -P ......... don't convert network port to service names
   -i <@h[:p]>. show connections to h (hostname|ip addr) with optional port p
 

 
file flags:
@@ -597,43 +656,69 @@ which calls finish.

   AP ......... append
   TR ......... truncate
 

-
Examples

-
Show open files with file flags:

+
Examples

+
File flags

+
Show open files with file flags for process:

 
lsof +fg -p <pid>
 

-
Show open tcp connections from user:

+
Open TCP connections

+
Show open tcp connections for $USER:

 
lsof -a -u $USER -i tcp
 

-
Show open connections to 'localhost' for user:

+
Note: -a ands the results. If -a is not given all open files matching
+$USER and all tcp connections are listed (ored).

+
Open connection to specific host

+
Show open connections to localhost for $USER:

 
lsof -a -u $USER -i @localhost
 

 
pidstat(1)

-
Trace minor/major page faults.

-
pidstat -r -p <pid> [interval]
-  minor_pagefault: happens when the page needed is already in memory but not
-                   allocated to the faulting process, in that case the kernel
-                   only has to create a new page-table entry pointing to the
-                   shared physical page
-  major_pagefault: happends when the page needed is NOT in memory, the kernel
-                   has to create a new page-table entry and populate the
-                   physical page
+
pidstat [opt] [interval] [cont]
+  -U [user]     show username instead UID, optionally only show for user
+  -r            memory statistics
+  -d            I/O statistics
+  -h            single line per process and no lines with average
+

+
Page fault and memory utilization

+
pidstat -r -p <pid> [interval] [count]
+

+
minor_pagefault: Happens when the page needed is already in memory but not
+                 allocated to the faulting process, in that case the kernel
+                 only has to create a new page-table entry pointing to the
+                 shared physical page (not required to load a memory page from
+                 disk).
+
+major_pagefault: Happens when the page needed is NOT in memory, the kernel
+                 has to create a new page-table entry and populate the
+                 physical page (required to load a memory page from disk).
+

+
I/O statistics

+
pidstat -d -p <pid> [interval] [count]
 

 
/usr/bin/time(1)

 
# statistics of process run
 /usr/bin/time -v <cmd>
 

-
pmap(1)

-
pmap <pid>
-  ............. dump virtual memory map of process.
-                compared to /proc/<pid>/maps it shows the size of the mappings
+
pgrep(1)

+
pgrep [opts] <pattern>
+  -n         only list newest matching process
+  -u <usr>   only show matching for user <usr>
+  -l         additionally list command
+  -a         additionally list command + arguments
+

+
Debug newest process

+
For example attach gdb to newest zsh process from $USER.

+
gdb -p $(pgrep -n -u $USER zsh)
 

 
pstack(1)

 
pstack <pid>
-  ............. dump current stack of process + threads
+    Dump stack for all threads of process.
+

+
pstack(1)

+
pstack <pid>
+    Dump stack for all threads of process.
 

 
perf(1)

-
perf list
-  ......... show supported hw/sw events
+
perf list      show supported hw/sw events
 
 perf stat
   -p <pid> .. show stats for running process
@@ -649,7 +734,8 @@ perf record
   -p <pid> ............... record stats for running process
   -F <hz> ................ sampling frequency
   --call-graph <method> .. [fp, dwarf, lbr] method how to caputre backtrace
-                           fp   : use frame-pointer, need -fno-omit-frame-pointer
+                           fp   : use frame-pointer, need to compile with
+                                  -fno-omit-frame-pointer
                            dwarf: use .cfi debug information
                            lbr  : use hardware last branch record facility
   -g ..................... short-hand for --call-graph fp
@@ -660,8 +746,7 @@ perf report
   --stdio ............... report to stdio, if not presen tui mode
   -g graph,0.5,caller ... show caller based call chains with value >0.5
 

-
Useful perf events

-
useful <ev>:
+
Useful <ev>:
   page-faults
   minor-faults
   major-faults
@@ -669,27 +754,26 @@ perf report
   task-clock
 

 
Flamegraph

-
# flamegraph for single event trace
-perf record -g -p <pid> -e cpu-cycles
+
Flamegraph with single event trace

+
perf record -g -e cpu-cycles -p <pid>
 perf script | FlameGraph/stackcollapse-perf.pl | FlameGraph/flamegraph.pl > cycles-flamegraph.svg
-
-# flamegraphs for multiple events trace
-perf record -g -p <pid> -e cpu-cycles,page-faults
+

+
Flamegraph with multiple event traces

+
perf record -g -e cpu-cycles,page-faults -p <pid>
 perf script --per-event-dump
 # fold & generate as above
 

-
OProfile

+
OProfile

 
operf -g -p <pid>
   -g ...... caputre call-graph information
 
 opreport [opt] FILE
-     ...... show time spent per binary image
+            show time spent per binary image
   -l ...... show time spent per symbol
   -c ...... show callgraph information (see below)
   -a ...... add column with time spent accumulated over child nodes
 
-ophelp
-     ...... show supported hw/sw events
+ophelp      show supported hw/sw events
 

 
od(1)

 
  od [opts] <file>
@@ -701,7 +785,7 @@ ophelp
     -j <n>      skip <n> bytes from <file> (hex if start with 0x)
     -N <n>      dump <n> bytes (hex of start with 0x)
 

-
ascii chars to hex string

+
ASCII to hex string

 
  echo -n AAAABBBB | od -An -w4 -tx4
     >> 41414141
     >> 42424242
@@ -711,13 +795,18 @@ ophelp
     >>         del   E   L   F  nl      # ta
     >>         177   E   L   F  \n      # tc
 

-
extract part of file (eg .rodata section form ELF)

+
Extract parts of file

+
For example .rodata section from an elf file. We can use readelf to get the
+offset into the file where the .rodata section starts.

 
  readelf -W -S foo
     >> Section Headers:
     >> [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
     >> ...
     >> [15] .rodata           PROGBITS        00000000004009c0 0009c0 000030 00   A  0   0 16
-  od -j 0x0009c0 -N 0x30 -tx4 -w4 foo
+

+
With the offset of -j 0x0009c0 we can dump -N 0x30 bytes from the beginning of
+the .rodata section as follows:

+
  od -j 0x0009c0 -N 0x30 -tx4 -w4 foo
     >> 0004700 00020001
     >> 0004704 00000000
     >> *
@@ -726,6 +815,7 @@ ophelp
     >> 0004750 00000003
     >> 0004754 00000004
 

+
Note: Numbers starting with 0x will be interpreted as hex by od.

 
xxd(1)

 
  xxd [opts]
     -p          dump continuous hexdump
@@ -733,19 +823,19 @@ ophelp
     -e          dump as little endian mode
     -i          output as C array
 

-
from ascii to hex stream

+
ASCII to hex stream

 
  echo -n 'aabb' | xxd -p
     >> 61616262
 

-
from hex stream to binary stream

+
Hex to binary stream

 
  echo -n '61616262' | xxd -p -r
     >> aabb
 

-
ascii to binary

+
ASCII to binary

 
  echo -n '\x7fELF' | xxd -p | xxd -p -r | file -p -
     >> ELF
 

-
ascii to C array (hex encoded)

+
ASCII to C array (hex encoded)

 
  xxd -i <(echo -n '\x7fELF')
     >> unsigned char _proc_self_fd_11[] = {
     >>   0x7f, 0x45, 0x4c, 0x46
@@ -773,7 +863,8 @@ ophelp
     -j <section>            display info for section
     --[no-]show-raw-insn    [dont] show object code next to disassembly
 

-
Disassemble .plt section

+
Disassemble section

+
For example .plt section:

 
  objdump -j .plt -d <elf>
 

 
nm(1)

@@ -782,10 +873,11 @@ ophelp
     -u          undefined only
 

 
c++filt(1)

-
demangle symbol

+
Demangle symbol

 
  c++-filt <symbol_str>
 

-
demangle stream (eg dynamic symbol table)

+
Demangle stream

+
For example dynamic symbol table:

 
  readelf -W --dyn-syms <elf> | c++filt
 

 
-- 
cgit v1.2.3