AFL `maybe_linking` regression

[choller]

In 3ef34c16697715d64fecfaed46c0e31e86fa9f01 the maybe_linking logic was removed, which will break any build system that invokes the compiler with -E for preprocessing only. We need to add the logic back at least for -E.

However, I am also concerned about the removal of the -shared case, which I added long ago to afl-clang-fast because it failed with mozilla-central otherwise. If multiple definitions of the runtime are linked into a single binary, the linker will deduplicate these in most cases (I wouldn't rely on this either, but I believe most modern linkers can deal with this). However, if you add the runtime to a shared library and a binary and then load the shared library into the binary, you will end up with two runtimes. This can potentially break stuff (we fixed this with sanitizers before, where it caused major problems).

I will try to come up with a PR later that adds the -E logic and maybe the -shared logic as well.

Cc @andreafioraldi

[choller]

Cc @vanhauser-thc

[andreafioraldi]

Some build systems seem to require to have afl-llvm-rt also when compiling, in fact they were failing with the old afl. Agree that -E is a special case, problably as you said the best option is to distinguish compilation and just preprocessing

[choller]

Some build systems seem to require to have afl-llvm-rt also when compiling, in fact they were failing with the old afl.

Yes, this is difficult to get right for AFL in the first place, because it requires the same logic as the sanitizer runtime linking logic and that one is complex enough.

However, -shared also should be excluded, because that is passed when linking a dso and there should never be any runtimes linked to those. I think I will try a combined patch for -E and -shared and see if that can build mozilla-central.