ci: use cross's edge images for multiarch test runs

The default `cross` images shipped with `cross 0.2.5` (2022) carry
pre-C++17 g++ toolchains, which can't compile the upgraded BoringSSL
(it needs C++17 headers like `<string_view>`). Override them with
`cross`'s `edge` images, which are rebuilt regularly from cross's
`main` branch and carry a current toolchain.

The `edge` image for `i686-unknown-linux-gnu` is set up differently
from the others: it's a 32-bit-native userspace shipping only the
unprefixed `gcc`/`g++` toolchain, missing some of the 32-bit dev
libraries needed by `cmake`'s compiler-detection probe, and lacks
the cross-prefixed binary names that `cross` and `cc-rs` expect.
Add a `pre-build` step to install `libc6-dev-i386 g++-multilib` and
to symlink `i686-linux-gnu-gcc`/`-g++` to the unprefixed
compilers.

Separately, BoringSSL's x86 assembly requires SSE2. The 32-bit
toolchain file sets `-msse2`, but cmake-rs passes
`-DCMAKE_C_FLAGS=...` on the command line which wins over the
toolchain file's CACHE STRING, leaving SSE2 unset in the actual build
flags. Add `-msse2` (and `-mfpmath=sse`) for the x86 build path in
`build.rs` so they make it into the final flags regardless.

An earlier attempt switched the multiarch CI job from `cross` to
native apt cross-toolchains plus `qemu-user-static`. That approach
worked but `qemu-user-static` introduced enough nondeterminism in
microsecond-level timing that several BBR2-parameterized byte-count
assertions started flaking on aarch64 and armv7 across different runs
of the same code. `cross`'s Docker+QEMU setup is deterministic
enough in practice to keep those tests stable, so we keep using
`cross` and address its toolchain age via `Cross.toml`.

Author: cjpatton

Cross.toml

@@ -0,0 +1,29 @@
+# Use `cross`'s `edge` images instead of the default `latest` (pinned to
+# cross 0.2.5, published 2022). The stock `latest` images for these
+# targets ship pre-C++17 g++ toolchains, which can't build BoringSSL 5.x
+# (it requires C++17 headers like `<string_view>`). The `edge` images
+# are rebuilt regularly from cross's `main` branch and carry a newer
+# toolchain.
+
+[target.aarch64-unknown-linux-gnu]
+image = "ghcr.io/cross-rs/aarch64-unknown-linux-gnu:edge"
+
+[target.armv7-unknown-linux-gnueabihf]
+image = "ghcr.io/cross-rs/armv7-unknown-linux-gnueabihf:edge"
+
+# The `edge` image for i686 is a 32-bit-native userspace and ships only
+# the unprefixed `gcc`/`g++` toolchain. We need:
+#   - 32-bit dev libraries (`Scrt1.o`, `crti.o`, etc.) so cmake's
+#     compiler-detection probe can link a trivial test program.
+#   - Symlinks for `i686-linux-gnu-{gcc,g++}` so `cross` (which sets
+#     `linker=i686-linux-gnu-gcc`) and `cc-rs`-based crates (e.g.,
+#     `ring`) can find a compiler under the cross-prefixed names they
+#     expect.
+[target.i686-unknown-linux-gnu]
+image = "ghcr.io/cross-rs/i686-unknown-linux-gnu:edge"
+pre-build = [
+    "dpkg --add-architecture i386",
+    "apt-get update && apt-get install --assume-yes libc6-dev-i386 g++-multilib",
+    "ln -sf /usr/bin/gcc /usr/local/bin/i686-linux-gnu-gcc",
+    "ln -sf /usr/bin/g++ /usr/local/bin/i686-linux-gnu-g++",
+]

quiche/src/build.rs

@@ -149,6 +149,16 @@ fn get_boringssl_cmake_config() -> cmake::Config {
                         .as_os_str(),
                 );
 
+                // BoringSSL's x86 assembly requires SSE2. The toolchain
+                // file sets `-msse2`, but cmake-rs passes
+                // `-DCMAKE_C_FLAGS=...` on the command line, which wins
+                // over the toolchain file's CACHE STRING. Add `-msse2`
+                // (and `-mfpmath=sse`) here so they make it into the
+                // final flags regardless.
+                boringssl_cmake.cflag("-msse2").cflag("-mfpmath=sse");
+                boringssl_cmake.cxxflag("-msse2").cxxflag("-mfpmath=sse");
+                boringssl_cmake.asmflag("-msse2");
+
                 boringssl_cmake
             },