wasmtime / issue #13122 cranelift-assembler-x64: generate... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #13122 cranelift-assembler-x64: generate...

Wasmtime GitHub notifications bot (Apr 16 2026 at 03:26):

travisdowns opened issue #13122:

Summary

cranelift/assembler-x64/build.rs writes absolute OUT_DIR paths into generated-files.rs with no sanitization:
for file in &built_files {
    writeln!(vec_of_built_files, "  {:?}.into(),", file.display()).unwrap();
}
This produces:
vec![
  "/home/alice/wasmtime/target/debug/build/cranelift-assembler-x64-abc123/out/assembler.rs".into(),
]
On released versions (v32.0.0 and earlier), generated-files.rs was include!'d in lib.rs via a pub fn generated_files(), which meant the absolute path got compiled into every binary linking the library — including downstream projects that only use cranelift as a dependency. On main, the no_std refactor (63330f11f5) moved the include! out of lib.rs into main.rs only, so the library is no longer affected. But generated-files.rs and the utility binary still contain the absolute path.

Related: #13121 — the cranelift-codegen side of this was already fixed by 0694bba38 ("Strip prefixes in file names").

The tension

There's a tension here between two goals:

Deterministic library output: the library should not embed build-specific absolute paths

Useful utility binary: main.rs prints paths to generated code, which is most useful as absolute paths

On main, the first goal is already satisfied (the include! was moved out of lib.rs). For the second, main.rs could reconstruct the absolute path at runtime using env!("OUT_DIR") while keeping the source text deterministic.

One possible approach: have build.rs write only the filename relative to OUT_DIR into generated-files.rs, and have main.rs join it with env!("OUT_DIR") at compile time:
// build.rs: write relative filename
let relative = file.strip_prefix(out_dir).expect("generated file should be under OUT_DIR");
writeln!(vec_of_built_files, "  std::path::Path::new(env!(\"OUT_DIR\")).join({:?}).into(),", relative.display()).unwrap();
This keeps generated-files.rs deterministic while the compiled binary still prints the correct absolute path (since env!("OUT_DIR") is resolved at compile time by rustc, not baked into the source text).

But I'm not sure how important the determinism of the utility binary itself is to the project — happy to hear what approach you'd prefer.

Reproducer
cd wasmtime
CARGO_TARGET_DIR=/tmp/build1 cargo build -p cranelift-assembler-x64
cat /tmp/build1/debug/build/cranelift-assembler-x64-*/out/generated-files.rs
# → absolute path to /tmp/build1/...
Environment

Discovered building wasmtime v32.0.0 via Bazel (rules_rust) with sandboxed execution

On v32.0.0, this caused non-determinism in the library (and all downstream binaries)

On main, library is no longer affected but generated-files.rs and the utility binary still are

Wasmtime GitHub notifications bot (Apr 16 2026 at 03:46):

travisdowns closed issue #13122:

Summary

cranelift/assembler-x64/build.rs writes absolute OUT_DIR paths into generated-files.rs with no sanitization:
for file in &built_files {
    writeln!(vec_of_built_files, "  {:?}.into(),", file.display()).unwrap();
}
This produces:
vec![
  "/home/alice/wasmtime/target/debug/build/cranelift-assembler-x64-abc123/out/assembler.rs".into(),
]
On released versions (v32.0.0 and earlier), generated-files.rs was include!'d in lib.rs via a pub fn generated_files(), which meant the absolute path got compiled into every binary linking the library — including downstream projects that only use cranelift as a dependency. On main, the no_std refactor (63330f11f5) moved the include! out of lib.rs into main.rs only, so the library is no longer affected. But generated-files.rs and the utility binary still contain the absolute path.

Related: #13121 — the cranelift-codegen side of this was already fixed by 0694bba38 ("Strip prefixes in file names").

The tension

There's a tension here between two goals:

Deterministic library output: the library should not embed build-specific absolute paths

Useful utility binary: main.rs prints paths to generated code, which is most useful as absolute paths

On main, the first goal is already satisfied (the include! was moved out of lib.rs). For the second, main.rs could reconstruct the absolute path at runtime using env!("OUT_DIR") while keeping the source text deterministic.

One possible approach: have build.rs write only the filename relative to OUT_DIR into generated-files.rs, and have main.rs join it with env!("OUT_DIR") at compile time:
// build.rs: write relative filename
let relative = file.strip_prefix(out_dir).expect("generated file should be under OUT_DIR");
writeln!(vec_of_built_files, "  std::path::Path::new(env!(\"OUT_DIR\")).join({:?}).into(),", relative.display()).unwrap();
This keeps generated-files.rs deterministic while the compiled binary still prints the correct absolute path (since env!("OUT_DIR") is resolved at compile time by rustc, not baked into the source text).

But I'm not sure how important the determinism of the utility binary itself is to the project — happy to hear what approach you'd prefer.

Reproducer
cd wasmtime
CARGO_TARGET_DIR=/tmp/build1 cargo build -p cranelift-assembler-x64
cat /tmp/build1/debug/build/cranelift-assembler-x64-*/out/generated-files.rs
# → absolute path to /tmp/build1/...
Environment

Discovered building wasmtime v32.0.0 via Bazel (rules_rust) with sandboxed execution

On v32.0.0, this caused non-determinism in the library (and all downstream binaries)

On main, library is no longer affected but generated-files.rs and the utility binary still are

Last updated: May 03 2026 at 22:13 UTC