push to stable

This commit fixes a sloppy function call that should normally check the number of insn's Operand before calling insn's getOperand method. The fix is that if it is 0 it should continue the loop.
I solved problem #1688 (comment) using this modification

fix getOperand out of range

display instance name

…FL_INIT() etc.

With the right -W options, compilers may complain about the cast of
string literals (for PERSIST_SIG and DEFER_SIG) to (char*), and they're
right to do so, because string literals are constant. Since some
projects enable -Werror, this can lead to a broken build with afl-cc.

Let's simply cast to (const char *), which preserves the constness of
the string literal.

afl-cc: Avoid casts of string literals to char*, in definition of __AFL_INIT() etc.

Since clang 16 is the version for Ubuntu 23 04/Fedora 38 and is easy enough to fix..

instrumentation/README.persistent_mode.md documents in the section about
deferred forkserver initialization:

> With the location selected, add this code in the appropriate spot:
>
> ```c
> #ifdef __AFL_HAVE_MANUAL_CONTROL
>   __AFL_INIT();
> #endif
> ```
>
> You don't need the #ifdef guards, but including them ensures that the program
> will keep working normally when compiled with a tool other than afl-clang-fast/
> afl-clang-lto/afl-gcc-fast.
>
> Finally, recompile the program with afl-clang-fast/afl-clang-lto/afl-gcc-fast
> (afl-gcc or afl-clang will *not* generate a deferred-initialization binary) -
> and you should be all set!


This strongly implies that you can compile a program that uses __AFL_INIT()
under an `#ifdef __AFL_HAVE_MANUAL_CONTROL` guard with afl-gcc/-clang.

However, this currently fails:

  $ cat example.c
  #include <stdio.h>

  int main(void) {
  #ifdef __AFL_HAVE_MANUAL_CONTROL
  	__AFL_INIT();
  #endif

  	puts("Hello");
  }
  $ afl-gcc example.c -o example
  afl-cc++4.06a by Michal Zalewski, Laszlo Szekeres, Marc Heuse - mode: GCC-GCC
  [!] WARNING: You are using outdated instrumentation, install LLVM and/or gcc-plugin and use afl-clang-fast/afl-clang-lto/afl-gcc-fast instead!
  afl-as++4.06a by Michal Zalewski
  [+] Instrumented 1 locations (64-bit, non-hardened mode, ratio 100%).
  /usr/bin/ld: /tmp/ccuJHcpt.o: in function `main':
  /home/jn/dev/fuzz/AFLplusplus/example.c:5: undefined reference to `__afl_manual_init'
  collect2: error: ld returned 1 exit status


The issue here is an inconsistency in afl-gcc (i.e. afl-cc operating in GCC mode):

 - afl-cc defines __AFL_HAVE_MANUAL_CONTROL and __AFL_INIT unconditionally
 - __AFL_INIT relies on __afl_manual_init, which is defined in afl-compiler-rt.o
 - afl-cc doesn't link afl-compiler-rt in GCC or CLANG mode


Since afl-gcc/-clang is documented as not supporting deferred forkserver
initialization, this patch omits the definitions of __AFL_HAVE_MANUAL_CONTROL
and related macros in GCC/CLANG mode.

This restores the ability to compile a deferred-forkserver program under
afl-gcc, if it can also be compiled under gcc.

[ In case someone reads this an feels adventurous enough (as I did) to
  think about enabling deferred forkserver under afl-gcc: Whether the
  deferred forkserver actually works can be verified by placing a
  usleep(100000) or similar at the start of main (before __AFL_INIT()),
  and watching the execution speed. It doesn't work. ]

LLVM instrumentation disable build warning.

afl-cc: Don't offer __AFL_INIT() etc. in GCC/CLANG modes

push to stable

push to stable

doc: fix logo link in README.md

push to stable

Might as well recommend installing 14, as that's newer, and what's used
in Docker.

Also remove outdated Dockerfile versions, likely easier to remove
versions here entirely, and anyone that wants to see what version is
used, can look in the Dockerfile.

doc: recommend llvm/clang-14 in docs

push to stable

Support for instrumentation more than GB away from data structures

Changes to support defered start

push to stable

Currently, if I build like with Clang, I'll get:
```bash
make LLVM_CONFIG=llvm-config-15 CC=clang-15 CXX=clang++-15
<snip>
[+] Everything seems to be working, ready to compile. (gcc version 12.1.0 (Ubuntu 12.1.0-2ubuntu1~22.04) )
clang-15 -O2 -D_FORTIFY_SOURCE=1 ....
```

Which is somewhat confusing. Fix this, and in a way that still outputs
the correct version info for Clang and GCC. Use `--version`, and pick
the first line, as that is where they are consistent in output. `clang
-v` gives the version first, whereas `gcc -v` gives the version on the
last line.

We switch to using $(CC), otherwise we also get incorrect output,
and dropping CCVER altogether, given this is it's only use.

build: fix compiler version in build output

…rror

Fix llvm 17 pcguard compile error

Adjust version check to only warn for LLVM 17.x and newer, which are the
development versions. Otherwise we'll get:
```bash
make LLVM_CONFIG=llvm-config-15 CC=clang-15 CXX=clang++-15
<snip>
GNUmakefile.llvm:69: you are using an in-development llvm version - this might break llvm_mode!
```

for versions that are supported, and not in development.

build: adjust LLVM development version check