fix merge conflicts

1 files changed, 30 insertions, 7 deletions

diff --git a/docs/FAQ.md b/docs/FAQ.md
index 714d50eb..0f447044 100644
--- a/docs/FAQ.md
+++ b/docs/FAQ.md
@@ -3,6 +3,7 @@
 ## Contents
 
   * [What is the difference between afl and afl++?](#what-is-the-difference-between-afl-and-afl)
+  * [I got a weird compile error from clang](#i-got-a-weird-compile-error-from-clang)
   * [How to improve the fuzzing speed?](#how-to-improve-the-fuzzing-speed)
   * [How do I fuzz a network service?](#how-do-i-fuzz-a-network-service)
   * [How do I fuzz a GUI program?](#how-do-i-fuzz-a-gui-program)
@@ -35,6 +36,26 @@ flexible and feature rich guided fuzzer available as open source.
 And in independent fuzzing benchmarks it is one of the best fuzzers available,
 e.g. [Fuzzbench Report](https://www.fuzzbench.com/reports/2020-08-03/index.html)
 
+## I got a weird compile error from clang
+
+If you see this kind of error when trying to instrument a target with afl-cc/
+afl-clang-fast/afl-clang-lto:
+```
+/prg/tmp/llvm-project/build/bin/clang-13: symbol lookup error: /usr/local/bin/../lib/afl//cmplog-instructions-pass.so: undefined symbol: _ZNK4llvm8TypeSizecvmEv
+clang-13: error: unable to execute command: No such file or directory
+clang-13: error: clang frontend command failed due to signal (use -v to see invocation)
+clang version 13.0.0 (https://github.com/llvm/llvm-project 1d7cf550721c51030144f3cd295c5789d51c4aad)
+Target: x86_64-unknown-linux-gnu
+Thread model: posix
+InstalledDir: /prg/tmp/llvm-project/build/bin
+clang-13: note: diagnostic msg: 
+********************
+```
+Then this means that your OS updated the clang installation from an upgrade
+package and because of that the afl++ llvm plugins do not match anymore.
+
+Solution: `git pull ; make clean install` of afl++
+
 ## How to improve the fuzzing speed?
 
   1. Use [llvm_mode](docs/llvm_mode/README.md): afl-clang-lto (llvm >= 11) or afl-clang-fast (llvm >= 9 recommended)
@@ -167,13 +188,7 @@ Four steps are required to do this and it also requires quite some knowledge
 of coding and/or disassembly and is effectively possible only with
 afl-clang-fast PCGUARD and afl-clang-lto LTO instrumentation.
 
-  1. First step: Identify which edge ID numbers are unstable
-
-     run the target with `export AFL_DEBUG=1` for a few minutes then terminate.
-     The out/fuzzer_stats file will then show the edge IDs that were identified
-     as unstable.
-
-  2. Second step: Find the responsible function(s).
+  1. First step: Instrument to be able to find the responsible function(s).
 
      a) For LTO instrumented binaries this can be documented during compile
         time, just set `export AFL_LLVM_DOCUMENT_IDS=/path/to/a/file`.
@@ -196,6 +211,14 @@ afl-clang-fast PCGUARD and afl-clang-lto LTO instrumentation.
         recompile with the two mentioned above. This is just for
         identifying the functions that have unstable edges.
 
+  2. Second step: Identify which edge ID numbers are unstable
+
+     run the target with `export AFL_DEBUG=1` for a few minutes then terminate.
+     The out/fuzzer_stats file will then show the edge IDs that were identified
+     as unstable in the `var_bytes` entry. You can match these numbers
+     directly to the data you created in the first step.
+     Now you know which functions are responsible for the instability
+
   3. Third step: create a text file with the filenames/functions
 
      Identify which source code files contain the functions that you need to