compiler-builtins: pass -fdebug-compilation-dir=. to fix S_OBJNAME reproducibility on Windows

[paradoxicalguy]

View all comments

compiler_builtins.rlib differs between builds because clang-cl embeds the absolute object output path into the S_OBJNAME codeview record.
the path comes from cc-rs passing an absolute /Fo argument (derived from cargo's OUT_DIR) to addDebugObjectName(), which llvm then writes verbatim into .debug$S.
minimal repro:

clang-cl /c /Z7 t.c /Fo:a\t.obj  →  ObjectName: C:\...\a\t.obj
clang-cl /c /Z7 t.c /Fo:b\t.obj  →  ObjectName: C:\...\b\t.obj

-fdebug-compilation-dir=. makes S_OBJNAME emit a relative path instead.
needs CI verification on a windows dist job since local builds use cl.exe rather than the bundled clang-cl. this pr is only for testing

[rustbot]

compiler-builtins is developed in its own repository. If possible, consider making this change to rust-lang/compiler-builtins instead.

cc @tgross35

[rustbot]

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Fallback group: @Mark-Simulacrum, @jieyouxu
• @Mark-Simulacrum, @jieyouxu expanded to Mark-Simulacrum, jieyouxu
• Random selection from Mark-Simulacrum, jieyouxu

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[rustbot]

⚠️ Warning ⚠️

• The following commits have merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged.

  • 9f5dbc0

  You can start a rebase with the following commands:

  $ # rebase
  $ git pull --rebase https://github.com/rust-lang/rust.git main
  $ git push --force-with-lease
  

[paradoxicalguy]

cc @bjorn3 @Urgau

[bjorn3]

@bors try job=dist-x86_64-msvc

[rust-bors]

☀️ Try build successful (CI)
Build commit: 5383ff6 (5383ff6bb690cf094a2399cf3e129092120625b2, parent: 9d862dd2c17b2dc90e9f623bb9279a8c4090b311)

[paradoxicalguy]

where can i download the x86_64-msvc artifact from this try build to extract ucmpti2.o and verify S_OBJNAME?

[bjorn3]

You can use rustup-toolchain-install-master I think you can do something like rustup-toolchain-install-master 5383ff6bb690cf094a2399cf3e129092120625b2 --host x86_64-pc-windows-msvc and then check ~/.rustup/toolchain/5383ff6bb690cf094a2399cf3e129092120625b2/lib/rustlib/x86_64-pc-windows-msvc/lib/libcompiler_builtins-*.rlib Afterwards you can remove it again with rustup toolchain remove 5383ff6bb690cf094a2399cf3e129092120625b2 I think. Make sure that rustup-toolchain-install-master downloads the correct commit, by default or if you pass the commit hash at the wrong location it downloads for the top of the main branch.

[ChrisDenton]

needs CI verification on a windows dist job since local builds use cl.exe rather than the bundled clang-cl. this pr is only for testing

IIRC you should be able to use something like --set target.x86_64-pc-windows-msvc.cc = "clang-cl.exe" to override the linker (or put the setting in your bootstrap.toml)

[paradoxicalguy]

thanks to both of you, i checked in downloaded artifact, sadly patch didn't work,
but now i can test this locally with --set target.x86_64-pc-windows-msvc.cc = "clang-cl.exe" so that's good

[tgross35]

Is this something that you can figure out by inspecting the object file? If so, you could create a PR to the compiler-builtins repo adding a failing test to https://github.com/rust-lang/compiler-builtins/blob/fb48f81544cf29e6ff7fb4468c8b2e1dacd42b79/crates/symbol-check/src/main.rs then messing around to see what flags get it to pass. Might be easier than repeating the try build process here.

Why does this only apply to Windows, though, and only compiler-builtins? I'd expect other platforms to get the same paths in their debug info.

[paradoxicalguy]

(a) yes, i found the current problem by inspecting an object file, extracting ucmpti2.o and running llvm-readobj --codeview on it, shows S_OBJNAME containing absolute path. (it came empty on my local patch but comes absolute path on ci so i am missing something, maybe different bootstrap or some flags.)
(b) on elf, it only saves the filename and not the whole path, not resulting in non determinism.
while codeview's S_OBJNAME record was designed to store the full absolute object path, since windows debugging tools (visual studio, windbg) use it to locate the original .obj on disk.

@tgross35

[paradoxicalguy]

it works w build.flag("/clang:-object-file-name="); in compiler-builtins repo.

[paradoxicalguy]

repro_report.html

the objname issue is resolved when checked manually but compiler-builtins still comes as non-deterministic in the repro check run i did. archive still contains absolute build paths (e.g. the build-b/extra1/... path), so im investigating whether those are coming from archive member names / the archive string table.