envoyproxy / envoyproxy/toolshed

Make @llvm_toolchain_llvm resolve to host-arch minimal LLVM artifacts (bzlmod alias) and source strip host-tools from the build tarballs

Open
#4,827 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
12
Forks
24
Avg merge
6h 37m
Merged PRs (30d)
92

Description

## Context

On the `llvm-min` branch the minimal LLVM pipeline now produces per-arch artifacts:

- `@llvm_minimal_linux_x64`
- `@llvm_minimal_linux_arm64`
- `@llvm_minimal_macos_arm64`

The intent going forward is: **everything consumes the minimal artifacts; the ONLY consumer of the full upstream LLVM is the build pipeline that produces the minimal artifacts.**

However the repo still references `@llvm_toolchain_llvm` (the single repo name that the `toolchains_llvm` `llvm.toolchain()` extension exports) in several places, and that repo is no longer the right source now that artifacts are per-arch. Current references (`git grep llvm_toolchain_llvm`):

- `bazel/MODULE.bazel`: `use_repo(llvm, "llvm_toolchain", "llvm_toolchain_llvm")`
- `bazel/compile/BUILD`: `_LLVM_MINIMAL_HOST_STRIPPER = "@llvm_toolchain_llvm//:bin/llvm-strip"`
- `bazel/compile/BUILD`: `_LLVM_MINIMAL_HOST_READOBJ = "@llvm_toolchain_llvm//:bin/llvm-readobj"`
- `bazel/compile/libcxx_libs.bzl`: `ctx.path(Label("@llvm_toolchain_llvm//:include/x86_64-unknown-linux-gnu/c++/v1/__config_site"))`
- `bazel/compile/test/BUILD.bazel` (multiple): `@llvm_toolchain_llvm//:nm`, `@llvm_toolchain_llvm//:readelf`, and `LLVM_NM` / `LLVM_READELF` env set via `$(rootpath @llvm_toolchain_llvm//:nm)` / `$(rootpath @llvm_toolchain_llvm//:readelf)`

## Goal

1. **`@llvm_toolchain_llvm` must resolve to the host-arch minimal LLVM artifact**, so all the non-build-pipeline references above keep working without rewriting each ref site. This is a bzlmod repo — you cannot `alias` across repos directly in `MODULE.bazel`, so create an alias/redirect repo via a module extension + repository rule.

2. **The strip host-tools used to BUILD the minimal artifacts must NOT come from `@llvm_toolchain_llvm`** (that would be circular — stripping the minimal artifact using tools sourced from the minimal artifact). They must come from the upstream tarball repos the pipeline already downloads (`@llvm_tarball_linux_x86_64` etc., host is x64).

## Required work

### A. Repoint the strip host-tools to the build tarballs
In `bazel/compile/BUILD`, change:
- `_LLVM_MINIMAL_HOST_STRIPPER` from `@llvm_toolchain_llvm//:bin/llvm-strip` to `@llvm_tarball_linux_x86_64//:bin/llvm-strip`
- `_LLVM_MINIMAL_HOST_READOBJ` from `@llvm_toolchain_llvm//:bin/llvm-readobj` to `@llvm_tarball_linux_x86_64//:bin/llvm-readobj`

These tools run at build time on the (x64) host to produce the minimal artifacts, so they should be sourced from the full upstream tarball that the pipeline already fetches, keeping the producer self-contained and non-circular. Confirm `@llvm_tarball_linux_x86_64` exposes `bin/llvm-strip` / `bin/llvm-readobj` (it globs `bin/**` via the `bin_all` filegroup and `exports_files` — verify the exact label form works; if `bin/llvm-strip` isn't directly a target, expose it).

### B. Create a host-arch alias repo named `llvm_toolchain_llvm`
Add a repository rule + module extension (in `bazel/compile/`, alongside the existing `llvm_minimal.bzl` / `extensions.bzl`) that creates a repo named `llvm_toolchain_llvm` which, at fetch time, resolves the HOST arch/os via `repository_ctx.os` and points at the matching minimal repo:

- host linux + x86_64 -> `@llvm_minimal_linux_x64`
- host linux + aarch64 -> `@llvm_minimal_linux_arm64`
- host macos + aarch64 -> `@llvm_minimal_macos_arm64`

Host-arch (fetch-time) resolution is correct here because every remaining `@llvm_toolchain_llvm` reference is a host/exec-side artifact (llvm-strip, llvm-readobj, nm, readelf, and the `__config_site` header consumed via `ctx.path` in a repo rule). There is no target-platform `select` requirement, which is important because one of the references (`libcxx_libs.bzl`) uses `ctx.path(Label(...))` at repo-fetch time and therefore cannot go through a target-level `alias` + `select`.

The alias repo must satisfy BOTH kinds of reference:

- **Label references** (`//:nm`, `//:readelf`, `//:bin/llvm-strip`, `//:bin/llvm-readobj`): expose these as targets. The minimal artifact's baked BUILD already defines `:nm` (-> `bin/llvm-nm`), `:readelf` (-> `bin/llvm-readelf`) filegroups and `exports_files` for `bin/*`. The alias repo can re-expose them via `alias()` targets pointing at `@llvm_minimal_//:nm` etc., and for the file labels either `alias()` to the exported file or symlink the file in.
- **`ctx.path` file reference** (`@llvm_toolchain_llvm//:include/x86_64-unknown-linux-gnu/c++/v1/__config_site`): this needs a REAL file at that path inside the repo. Symlink the chosen `@llvm_minimal_` tree's `bin/`, `lib/`, `include/` into the alias repo root so the file path resolves.

The simplest robust implementation is likely: in the repo rule, `symlink` the chosen minimal repo's `bin`, `lib`, `include` directories into the alias repo, then write a `BUILD.bazel` that re-exposes the needed filegroups/aliases (`nm`, `readelf`, `bin/llvm-strip`, `bin/llvm-readobj`, and `exports_files` covering `bin/**`, `include/**`). Verify that both `bazel build @llvm_toolchain_llvm//:nm` and the `ctx.path` lookup resolve.

### C. Wire it in MODULE.bazel without a name collision
`bazel/MODULE.bazel` currently gets `llvm_toolchain_llvm` from the `toolchains_llvm` extension:
```
use_repo(llvm, "llvm_toolchain", "llvm_toolchain_llvm")
```
You cannot have two repos named `llvm_toolchain_llvm`. Remove `llvm_toolchain_llvm` from that `use_repo` and export the name from the new extension instead, e.g.:
```
llvm_toolchain_alias_ext = use_extension("//compile:extensions.bzl", "llvm_toolchain_alias_extension", dev_dependency = True)
use_repo(llvm_toolchain_alias_ext, "llvm_toolchain_llvm")
```
(Keep `llvm_toolchain` from the toolchains_llvm extension — only `llvm_toolchain_llvm` is being repointed.)

### Scope boundary — DO NOT change the toolchain registration
Leave the `llvm.toolchain()` / `llvm.cxx_cross_lib()` / `llvm.sysroot()` block and `register_toolchains("@llvm_toolchain//:all", ...)` (MODULE.bazel lines ~106-138) UNCHANGED. Switching the actual compile toolchain to consume the minimal artifacts (via `toolchain_roots`) is a SEPARATE change (tracked elsewhere) and is explicitly out of scope here. This issue only:
- repoints the strip host-tools (A),
- adds the host-arch `@llvm_toolchain_llvm` alias repo (B),
- rewires the `use_repo` for that name (C).

## Verification (do not finish without it)
- `bazel build @llvm_toolchain_llvm//:nm @llvm_toolchain_llvm//:readelf` resolves on a linux-x64 host and points at the minimal artifact's `llvm-nm` / `llvm-readelf`.
- The `//compile:llvm_minimal_linux_x86_64` build still works with the strip tools now sourced from `@llvm_tarball_linux_x86_64` (the produced tar still has stripped `clang-22`/`lld` and symlink aliases — do not regress the symlink/strip fix already on `llvm-min`).
- `bazel build //compile/test/...` (the tests that reference `@llvm_toolchain_llvm//:nm` / `:readelf` and set `LLVM_NM` / `LLVM_READELF`) still resolve those labels.
- `bazel mod deps` / a bzlmod load succeeds with no duplicate `llvm_toolchain_llvm` repo and no unresolved `@llvm_toolchain_llvm` reference.

## Notes / latent issue to flag (not necessarily fix here)
- `bazel/compile/libcxx_libs.bzl` hardcodes `x86_64-unknown-linux-gnu` in the `__config_site` path. On an aarch64 host the alias repo would point at `@llvm_minimal_linux_arm64` whose config_site lives under a different triple (`aarch64-unknown-linux-gnu`), so this path would not resolve. Out of scope to fix, but note it in the PR so it's tracked.

## Constraints
- Work on the `llvm-min` branch.
- Keep the two-pass strip/symlink algorithm and the `clang-22`/`lld` allowlist entries intact — do not regress the fix already on the branch.
- All new repo/extension code should live in `bazel/compile/` next to the existing minimal LLVM machinery and be `dev_dependency` consistent with the surrounding LLVM setup.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with bazel/compile/BUILD, the existing bazel/compile/llvm_minimal.bzl and extensions.bzl, and bazel/MODULE.bazel. Trace the minimal artifact repository layout and current extension wiring, then implement and verify the alias and tarball tool references with the listed bazel build, bazel mod deps, and compile/test commands. Done means the labels and ctx.path lookup resolve without a repo-name collision, while the minimal build still produces the expected stripped artifacts.

Written by the indexing model from the issue text.

Assessment

Domain
build-system, tooling
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.