Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use of tempfile for lib.def leads to non-reproducible PDBs #71714

Open
nikhilm opened this issue Apr 30, 2020 · 1 comment
Open

Use of tempfile for lib.def leads to non-reproducible PDBs #71714

nikhilm opened this issue Apr 30, 2020 · 1 comment
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) A-reproducibility Area: Reproducible / deterministic builds C-bug Category: This is a bug. O-windows-msvc Toolchain: MSVC, Operating system: Windows P-medium Medium priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@nikhilm
Copy link

nikhilm commented Apr 30, 2020

I've been working with a rust code base that we are trying to use a shared cache for (Bazel FWIW). As part of that I've been looking at truly bit-identical build outputs for a given set of inputs.

There are plenty of problems with PDB files on Windows (which contain debug info) because they tend to encode absolute paths to the object files and other resources they were created from. I've managed to eliminate most of these by using deterministic build directories across all machines, and using tempdir's that are a hash of something unique. There is just one more bit that I can't control directly, which is this use of tmpdir.join("lib.def")

let path = tmpdir.join("lib.def");
. This ends up putting a few random characters in the path that throws off the PDB.

I'm not entirely sure what a good solution will look like. I'm not familiar enough with compiler internals to know if some deterministic location based on some unique values can be used, or alternatively if this can be exposed as a compiler option.

I tried this code:
I can't share our internal code, but build something like serde_derive on windows and look for the proc macro dll. there should be a pdb next to it.
Next, you'll want to use ducible https://github.com/jasonwhite/ducible/ to remove a few other sources of non-determinism like timestamps.

ducible <dll> <pdb>

I expected to see this happen: Each clean build results in the same DLL and PDB (sha256 or similar).

Instead, this happened: the DLL is identical but the PDBs are not. Use something like https://www.cjmweb.net/vbindiff/ to spot the differences and the only one i noticed was this path to lib.def.

Meta

(also exists in latest master based on code inspection).
rustc --version --verbose:

rustc 1.42.0-nightly (212b2c7da 2020-01-30)
binary: rustc
commit-hash: 212b2c7da87f3086af535b33a9ca6b5242f2d5a7
commit-date: 2020-01-30
host: i686-pc-windows-msvc
release: 1.42.0-nightly
LLVM version: 9.0
@nikhilm nikhilm added the C-bug Category: This is a bug. label Apr 30, 2020
@wesleywiser wesleywiser added O-windows-msvc Toolchain: MSVC, Operating system: Windows A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) labels Apr 30, 2020
@jonas-schievink jonas-schievink added A-reproducibility Area: Reproducible / deterministic builds T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 30, 2020
@wesleywiser wesleywiser added the P-medium Medium priority label Jun 19, 2023
@wesleywiser
Copy link
Member

Visited during wg-debugging triage. A number of other reproducibility issues are being looked at currently. Hopefully we can fix this soon. Marking P-medium.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) A-reproducibility Area: Reproducible / deterministic builds C-bug Category: This is a bug. O-windows-msvc Toolchain: MSVC, Operating system: Windows P-medium Medium priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants