fix: remap assembler debug paths in Cargo build scripts

[titusfortner]

Problem

Selenium's CI broke due to a rules_rs bug (hermeticbuild/rules_rs#238). That bug was fixed in 0.0.108, but we can't upgrade to that version because our remote executor uses gcc 9 and hits a hermeticity bug.

ring and zstd-sys compile hand-written assembly in their build scripts. rules_rust passes -ffile-prefix-map=${pwd}=. so the build directory never appears in compiled output, but gcc 12 and older don't forward that flag to the assembler. The assembler records the absolute build directory in the object's debug info, cc-rs archives the object, rustc bundles the archive into the rlib, and --check-output-for-working-dir fails the build:

compiled Rust output .../libring-1490277151.rlib embeds the absolute working directory
/mnt/engflow/worker/work/0/exec. Do not retain env!("CARGO_MANIFEST_DIR") or
env!("OUT_DIR") in compiled code; ...

The message points at Rust source, but the path comes from the assembly.

This only affects gcc 12 and older (upstream GCC added the forwarding in 13; Ubuntu's gcc-12 backports it) and only in fastbuild and dbg, where cc-rs passes -g. clang assembles .S itself, so it's unaffected.

Solution

Add -fdebug-prefix-map=${pwd}=. which gcc forwards to the assembler. The assembly gets rewritten along with everything else, and the rlib stops depending on where it was built. The flag is redundant and harmless for gcc 13+.

Additional considerations

• Still need to include -ffile-prefix-map since it also implies -fmacro-prefix-map, which covers __FILE__, so dropping it would trade one leaked path for another.
• Clang rejects passing -Wa,--debug-prefix-map directly, so that's not an option.
• MSVC never gets either flag, so Windows may have the same gap. I haven't looked.
• The check only catches this when the build script and rustc actions happen to run in the same directory. It compares against the working directory of the rustc action, but the path is written by the build script action, so under sandboxing or remote execution the two can differ and the check passes. Scanning build script output where it is produced would close that. I have it working and left it out of this PR, since it's a new check that could fail builds passing today.

[dzbarsky]

Ah, fun, thanks for the fix! BTW I thought Simon was trying to get Selenium working with @llvm (hermetic-llvm), do yall need help getting that over the finish line?