Change https://go.dev/cl/561595 mentions this issue: env/linux-x86-bullseye: add zlib1g to dependencies to install

This will take some time to propagate. I suspect it should look OK by tomorrow.

I added zlib to the image but it wasn't enough. I tracked down the problem to the fact that the official LLVM project's release of clang does NOT build llvm-symbolizer with zlib support.

This is unfortunate. The only alternative is to use a different clang. The nice thing about the current system I set up for LUCI is that clang is using just the regular official LLVM release maintained easily in CIPD, so it's easy to update, change, and manage.

A few available options (all unfortunate) are:

• Use the LLVM distro-packaged version of clang (they build llvm-symbolizer against zlib) and bake it into the image. (From https://apt.llvm.org, so at least it's official.)
  • This is unfortunate because we have to have a separate set of machines that contain clang, or we add clang to every linux-amd64 machine.
  • It makes updating clang harder, since clang isn't available in Debian by default. The package appears to need to be manually added.
• Use Chromium's clang build, which likely (though I haven't confirmed) has it.
  • It feels wrong to pin ourselves to a custom clang build that also isn't owned by us.
• Make the process for adding a new clang build involve building clang ourselves.
  • This seems overly onerous and building against a (technically) custom clang seems like the wrong call.

However, there's a different direction we can take.

The ASAN tests already skip checking for file and line numbers (symbolized results) in the output on old GCC versions. However, AFAICT, the version of GCC on our builders does actually symbolize the output. I think the primary purpose of these tests is to make sure our debug information is working correctly, not necessarily integration with specific toolchains. So, theoretically, we have coverage on our debug information working properly already.

What I propose:

1. File a bug against upstream LLVM to build against zlib in their releases.
2. Skip the symbolization part of the test for clang.
3. File a bug to track turning this part of the test back on once LLVM upstream (hopefully) starts building their releases against zlib.

Based on the thread I found this request seems reasonable to the LLVM maintainers. I'll note that apparently the exact LLVM configuration used in the release is up to whoever is doing the release anyway, so my assumption is that there are already some inconsistencies in their process, and requiring zlib probably wouldn't be too hard on users of clang. But I don't know.

Change https://go.dev/cl/562675 mentions this issue: cmd/cgo/internal/testsanitizers: disable location checking for clang

Change https://go.dev/cl/562538 mentions this issue: env/linux-x86-bullseye: add clang to image

@gopherbot Please open backport issues for Go 1.21 and Go 1.22. The LUCI clang builder on those branches is currently broken, and we should cherry-pick the fix applied here.

Backport issue(s) opened: #65640 (for 1.21), #65641 (for 1.22).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

Change https://go.dev/cl/563015 mentions this issue: [release-branch.go1.22] cmd/cgo/internal/testsanitizers: disable location checking for clang

Change https://go.dev/cl/562999 mentions this issue: [release-branch.go1.21] cmd/cgo/internal/testsanitizers: disable location checking for clang