6c597be1c6
Unfortunately, this requires partially reverting https://boringssl-review.googlesource.com/31324. This is a mess. While clang proper includes a fuzzer driver, Chromium doesn't use it. Chromium builds exclusively with fuzzer-no-link and links to its own copy of the fuzzer runtime[1]. As of [2], Chromium's clang (which we use on bots) no longer includes the driver, so we must mimic them. However, Chromium's setup is somewhat questionable because fuzzer-no-link pulls in libclang_rt.fuzzer_no_main which still includes most of libclang_rt.fuzzer, just not the one main function[3]. It appears Chromium is actually linking two copies of libclang_rt.fuzzer_no_main. Hopefully this mostly works out as Chromium's clang and libFuzzer should be relatively aligned, but it's not a good assumption for our build, which can take other Clangs too. Thus, if you pass -DFUZZ=1 as-is, we will assume you are using a "normal" Clang with all its relevant runtimes intact. If, however, you are using Chromium clang, you must drop the matching libFuzzer where the bots expected it and build with -DLIBFUZZER_FROM_DEPS=1. This involves no changes to the bots because we never actually unwound all the LIBFUZZER_FROM_DEPS bits before. [1] https://cs.chromium.org/chromium/src/testing/libfuzzer/BUILD.gn?rcl=d21c49585f262e851e2984f96f52905782706325&l=14 [2] |
||
|---|---|---|
| .. | ||
| go | ||
| cmake-linux64.tar.gz.sha1 | ||
| cmake-mac.tar.gz.sha1 | ||
| cmake-win32.zip.sha1 | ||
| DEPS | ||
| extract.py | ||
| nasm-win32.exe.sha1 | ||
| perl-win32.zip.sha1 | ||
| README | ||
| sde-linux64.tar.bz2.sha1 | ||
| sde-win32.tar.bz2.sha1 | ||
| update_clang.py | ||
| UPDATING | ||
| vs_env.py | ||
| vs_toolchain.py | ||
| yasm-win32.exe.sha1 | ||
This directory contains tools for setting up a hermetic toolchain on the continuous integration bots. It is in the repository for convenience and can be ignored in development.