`--crate-type=rlib` + `-Cdebuginfo=2` + `-Zremap-cwd-prefix=.` is not reproducible on Windows

[jieyouxu]

In #128456 (comment) we noticed that:

--crate-type=rlib + -C debuginfo=2 + -Z remap-cwd-prefix=. on Windows caused the rlib to be unreproducible.

rust/tests/run-make/reproducible-build/Makefile

Lines 4 to 5 in 0f442e2

	# ignore-musl
	# Objects are reproducible but their path is not.

Two source files:

1. https://github.com/rust-lang/rust/blob/0ba9db87e61adcfd9a978188f61c20d9b423a099/tests/run-make/reproducible-build/reproducible-build-aux.rs
2. https://github.com/rust-lang/rust/blob/0ba9db87e61adcfd9a978188f61c20d9b423a099/tests/run-make/reproducible-build/reproducible-build.rs

Steps:

• Let "root" test directory be called $base_dir.
• rustc reproducible-build-aux.rs
• mkdir test
• cp reproducible-build.rs test/reproducible-build.rs
• compiler 1: rustc --crate-type=rlib -C debuginfo=2 -Zremap-cwd-prefix=. -L $cwd reproducible-build.rs
• mv libreproducible_build.rlib libfoo.rlib
• cd test
• compiler 2: rustc --crate-type=rlib -C debuginfo=2 -Zremap-cwd-prefix=. -L $base_dir --out-dir=$base_dir reproducible-build.rs
• cd $base_dir
• check if libreproducible_build.rlib and libfoo.rlib are different

Marking as S-needs-repro as I'm not sure of the root cause or exact reproduction environment; the test case failed on x86_64-msvc ci job. I'm also not exactly sure of the intended semantics of -Z remap-cwd-prefix=..

[madhav-madhusoodanan]

Was trying to replicate this issue on windows.

Found that the --out-dir=$base_dir argument encodes $base_dir into the generated .rlib files when -Cdebuginfo=2 is being passed. Shouldn't this be the intended behaviour?

There also appears to be a diff of 4 bytes (2nd screenshot), which looks like a difference in CRC32 checksums.

I wasn't able to find these difference when -Cdebuginfo=2 was not being passed though.

Environment

> rustup toolchain list
nightly-x86_64-pc-windows-msvc (active, default)

> rustc --version
rustc 1.93.0-nightly (843f8ce2e 2025-11-07)

Mechanism of testing:

• Let "root" test directory be called $base_dir.
• rustc reproducible-build-aux.rs
• mkdir test2 test3
• compiler 1: rustc --crate-type=rlib -C debuginfo=2 -Zremap-cwd-prefix=. -L $base_dir reproducible-build.rs --out-dir=test2
• compiler 2: rustc --crate-type=rlib -C debuginfo=2 -Zremap-cwd-prefix=. -L $base_dir reproducible-build.rs --out-dir=test3
• Compare the generated files using Get-FileHash ".\path\to\libreproducible_build.rlib" -Algorithm SHA256

.rlib files after the above steps

madhav.zip

vbindiff outputs

[paradoxicalguy]

worked on this issue for ~2weeks and can confirm this issue is still reproducible on windows 11 with x86_64-pc-windows-msvc, used rust-nightly

what all i pinpointed:

• binary non-determinism remains the same even with -C split-debuginfo=off
• minimal repro: rustc <file>.rs --crate-type=rlib -C debuginfo=2 -Z remap-cwd-prefix=. -C split-debuginfo=off,
• result: different hashes on identical code and builds.

my current block:

• experimented building stage 1 rustc to debug this further but the windows bootstrap is defaulting to split-debuginfo=packed, which us causing STATUS_ACCESS_VIOLATION which crashes during stdlib compilation, while building core to be precise. this is what is majorly stopping me from moving any further in this issue.
• yet to try this but the way out might require ./x.py build --set rust.split-debuginfo=off, but i was unable to get a working stage 1 build itself, so yeah.

[paradoxicalguy]

i have narrowed down the possible root cause of this non determinism,

after performing a binary comparison of .rlib contents and inspecting exported object files using llvm-readobj --codeview, i found the following things:

1. the path leakage is originating from S_OBJNAME record inside .debug$S section of the COFF object files (.rcgu.o) which are bundled into .rlib
2. even with-Z remap-cwd-prefix=. enabled, full object output directory is embedded in the ObjectName field of the CodeView metadata, which is causing a byte difference in the embedded object path and a cascading checksum difference resulting in non-reproducible .rlib hashes.
3. even did cross-toolchain validating with a minimal C file:

clang-cl /Z7 /c t.c /Fo:out1\t.obj
clang-cl /Z7 /c t.c /Fo:out2\t.obj

this showed the same S_OBJNAME path leakage when inspected with llvm-readobj --codeview. suggesting this behavior is coming from llvm's default WinCOFF or codeview emission.

4. additional notes:
   the STATUS_CODE_VIOLATION (0xc0000005) i was encountering earlier is unrelated to this issue. its tied to a specific weird combination of split-debuginfo=packed and prefer-dynamic during building of core of stdlib in stage1. doesnt affect the .rlib non determinism described above

[paradoxicalguy]

update: resolved the windows build environment which was blocking, cant say directly resolved but maybe a workaround, by downgrading my Visual Studio to V143 (2022) which CI uses directly and keeping download-ci-llvm = true.
so stage1 rustc builds successfully on windows and the reproducible-build test fails correctly as expected.