Reland "Reland "[infra] Update Linux machines to use Clang 15.0.1""
This is a reland of commit 8704bb831d56f63158cfe420004e8d22c70b6c8d
LSAN suppressions were not working on Windows ASAN, and do not
appear necessary.
The output from the new version of ASAN appeared to choke up
the old llvm-symbolizer on the PATH of our test machines.
We don't really want to use that symbolizer anyway, so we
set the ASAN_SYMBOLIZER_PATH to use the new one from CIPD.
Original change's description:
> Reland "[infra] Update Linux machines to use Clang 15.0.1"
>
> This is a reland of commit 946da5eda4332e5cbcd73f6b4823be93db4919d8
>
> Original change's description:
> > [infra] Update Linux machines to use Clang 15.0.1
> >
> > The previous version was Clang 10. This only impacts our GN builds
> > (Bazel toolchain will need an update as well as a bit of
> > infrastructure to upload the compiled toolchain).
> >
> > We need to compile Clang from source for two reasons:
> > - https://github.com/llvm/llvm-project/releases/tag/llvmorg-15.0.1
> > does not have pre-built amd64 Linux binaries (v14 was
> > the last one, it seems).
> > - We need to compile libcxx and libcxxabi for MSAN and TSAN
> > to work properly [1] [2]
> >
> > This change compiles Clang using Docker for two reasons:
> > - Docker is more reproducible, which is easier to use and
> > lets us have better SLSA compliance.
> > - Our current Linux compile and test machines are running
> > Debian 10, which has libc version 2.28. If a dev (e.g. me)
> > compiled Clang on a newer version of Debian, it would
> > require a newer version of libc to be on the build machines,
> > which is non-trivial to accommodate.
> >
> > Getting the Docker build to work was a bit tricky, but the
> > official Clang project has a Dockerfile [3] that I cribbed from.
> >
> > Building libcxx and libcxxabi in a non-deprecated way required
> > small, subtle changes [4][5]
> >
> > We no longer add tools/xsan.supp to the include path because
> > Clang warns about "unrecognized pragmas", which is what it thinks
> > the suppression comments are. I think this originally had been
> > added to force re-compilation if the suppression changed (otherwise
> > ninja has no way to know something changed). In Bazel, this would
> > not be an issue (as toolchain contents are accounted for when
> > deciding to rebuild). For our GN builds, the risk is tolerable
> > given how infrequently we update that suppression file.
> >
> > We no longer compile the clang binaries in MinSizeRel mode.
> > I wasn't able to tell via git history why that was chosen in the
> > first place, but we have plenty of bandwidth and disk space on
> > our CI machines; time (i.e. execution time) is the precious
> > resource.
> >
> > [1] https://github.com/google/sanitizers/wiki/MemorySanitizer#using-instrumented-libraries
> > [2] https://github.com/llvm/llvm-project/blob/76fd4bf675b5ceeeca0e4e15cf15d89c7acf4947/llvm/utils/docker/debian10/Dockerfile
> > [3] https://github.com/google/sanitizers/wiki/ThreadSanitizerCppManual#non-instrumented-code
> > [4] https://libcxx.llvm.org/BuildingLibcxx.html
> > [5] https://stackoverflow.com/a/73827100/1447621
> >
> > Change-Id: I5c3c6c9bc61fa3c335647a2ff5b0abe259b0bbbb
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/583776
> > Reviewed-by: Ravi Mistry <rmistry@google.com>
> > Reviewed-by: Brian Osman <brianosman@google.com>
>
> Change-Id: I561fa5986e7dec72f24c27e4af0799efb6ad881d
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/584918
> Commit-Queue: Kevin Lubick <kjlubick@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: I627313b0fa5e0ef6c1e1a450d676b3c97e99002c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/592536
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
23 files changed