Change:
Spawned off of When passing to rustc I would expect all paths that start with to be replaced with , instead a is still present. Note that this happens even in release mode, because rustc always tells the msvc linker to generate files. This can be "fixed" by passing either , or to rustc, but doing so will break backtraces with ( already prints almost nothing in release mode). As a sidenote, do we really need backtraces in release mode, and by consequence files? They will break anyway if only the is distributed or the directory is deleted. Moreover this shouldn't be needed in the first place since promises to "remap source names in all output (compiler messages and output files)" (from the output of ), "including ). Also note that neither nor the rustc book mention the need to pass one of those arguments to rustc to remap/remove the path to the file, which makes it harder for non-experts to know how to remove them. :
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Perhaps this should be amended to say compiler output but not linker outputs. PDB files are generated at the linking step, which is probably why sees non-determinism for --crate-type=bin (linked) and not for --crate-type=rlib (not linked). Passing to the linker to put a relative path to the PDB files is probably the best choice, as it is the least destructive, and the debugger will look for PDB files next to the executables, so it will be able to find it. Chromium uses this for its Windows linking step as well: ;drc=;l=2358 Doing this with could work if you can figure out which "to-be-remapped" path is going to be the path being written by the linker, and then pass the resulting path to . I must confess I am not sure how linking is being done, but I assume the binary is being linked by a dedicated linker, not by rustc itself? If so that is not too reliable. rustc could provide a switch to remove the absolute path to PDB files, which would just map to . The value proposition there seems low, since you can pass that as the user anyway. Determinism is important for both release and debug builds, so I don't believe there is anything release-mode specific here or that a solution should be chosen that doesn't deal with debug mode? Could you say what is breaking about backtraces with ?
Without that flag I get something like: <details<summaryBacktrace</summary<p</p</detailsBut with it it just prints: <details<summaryBacktrace</summary<p</p</detailsThis seems to happen because the pdb file is searched relative to the current working directory, and when running that's often not the directory with the executable and pdb files. appears to work, but only as long as you execute it from the crate root, which is definitely not ideal.
Can move to the crate root before executing the target executable? Then cargo could pass (or debug) while other build systems pass or whatever works for them?
Wouldn't that break any workflow that relies on the current working directory always being where is executed from?
I think this meant the crate root instead of the cwd? I had no idea that would be a common thing, but you're right. It would change any use of . I would expect to be more commonly used for relative paths, as it doesn't depend on running from a cargo source tree, but maybe I am wrong. Regardless, I can see why changing behaviour isn't ideal. The MSVC linker doesn't present a whole lot of options though, as the path relative to where you plan to run the binary has to be encoded into the pdb files if you want a deterministic output. It seems the options are: -determinisic output, backtraces always work, debuggers work: PDB absolute paths. This is the default behaviour. output, , and backtraces work from the exe's directory: output, backtraces work from the crate root, but debuggers won't work: Have I missed an option? There's no option that I can see with both deterministic output and backtraces working from arbitrary working directories. AIUI, this github issue is about --remap-path-prefix not adding a flag, essentially. It would be nice if deterministic builds were easier to get! But based on all of the above, it seems to me that is better solved through Cargo than through rustc's , perhaps behind a Cargo flag in As a convenience, maybe could provide an option to move to the exe's directory to run it, instead of users doing , which would let option 2 be more ergonomic while also supporting debuggers.
Would it be possible to have create a symbolic link to the file or the directory when it's not already present in the current working directory? This would partially solve the ergonomic problems of approaches 2 and 3
It'd probably be easier to have set , which effect the default search path for the used for
Any update on this? :)
I've just opened which solves the problem by making always pass to the linker. This seems like the best solution to me. The PR is currently blocked on backtrace-rs not handling this properly, but I've opened , which will hopefully fix that.

Discussion:
// from the CodeView line tables in the object files. self.cmd.arg("/DEBUG"); <ins> // Default to emitting only the file name of the PDB file into // the binary instead of the full path. Emitting the full path // may leak private information (such as user names). // See https://github.com/rust-lang/rust/issues/87825. // // This default behavior can be overridden by explicitly passing // `-Clink-arg=/PDBALTPATH:...` to rustc. self.cmd.arg("/PDBALTPATH:%_PDB%"); </ins> // This will cause the Microsoft linker to embed .natvis info into the PDB file let natvis_dir_path = self.sess.sysroot.join("librustlibetc"); if let Ok(natvis_dir) = fs::read_dir(&natvis_dir_path) {

<ins> include ../tools.mk # only-windows-msvc all: # Test that we don't have the full path to the PDB file in the binary $(RUSTC) main.rs -g --crate-name my_crate_name --crate-type bin -Cforce-frame-pointers $(CGREP) "my_crate_name.pdb" < $(TMPDIR)/my_crate_name.exe $(CGREP) -v "my_crate_name.pdb" < $(TMPDIR)/my_crate_name.exe # Test that backtraces still can find debuginfo by checking that they contain symbol names and # source locations. $(TMPDIR)/my_crate_name.exe &> $(TMPDIR)/backtrace.txt $(CGREP) "my_crate_name::fn_in_backtrace" < $(TMPDIR)/backtrace.txt $(CGREP) "main.rs:15" < $(TMPDIR)/backtrace.txt # Test that explicitly passed `-Clink-arg=/PDBALTPATH:...` is respected $(RUSTC) main.rs -g --crate-name my_crate_name --crate-type bin -Clink-arg=/PDBALTPATH:abcdefg.pdb -Cforce-frame-pointers $(CGREP) "abcdefg.pdb" < $(TMPDIR)/my_crate_name.exe $(CGREP) -v "my_crate_name.pdb" < $(TMPDIR)/my_crate_name.exe </ins>

<ins> // The various #[inline(never)] annotations and std::hint::black_box calls are // an attempt to make unwinding as non-flaky as possible on i686-pc-windows-msvc. #[inline(never)] fn generate_backtrace(x: &u32) { std::hint::black_box(x); let bt = std::backtrace::Backtrace::force_capture(); println!("{}", bt); std::hint::black_box(x); } #[inline(never)] fn fn_in_backtrace(x: &u32) { std::hint::black_box(x); generate_backtrace(x); std::hint::black_box(x); } fn main() { let x = &41; std::hint::black_box(x); fn_in_backtrace(x); std::hint::black_box(x); } </ins>