Cross-compiled asm output has invalid mixed-slash paths

[evmar]

From a non-Windows computer, generate asm while cross compiling to Windows. The resulting file contains paths with a mixture of forwards and backwards slashes.

$ cargo new path-repro
$ cargo rustc --target i586-pc-windows-msvc -- --emit asm

(Note: even if the latter fails with a missing link.exe, the assembly is still generated and it still reproduces this bug.)

The resulting assembly file target/i586-pc-windows-msvc/debug/deps/path_repro.s contains path references like:

        .cv_file        1 "/rustc/e71f9a9a98b0faf423844bf0ba7438f29dc27d58\\library\\std\\src\\rt.rs" "13B62144D5451EAE559C4FD478A015CF18D734D1D8B9602FF13CE7C70FFA4F05" 3

These paths are invalid on the host (Mac) system.

I noticed in the same output that the input Rust files have Mac-style paths:

        .cv_file        9 "/Users/evmar/projects/path-repro/src/main.rs" "C8E0583694BB1E0188DBE28FE0D65AC1130723C55F968B6262B906C147F72549" 3

So I think I expect the all paths to be fully forward slashed.

This matters for tools that want to parse and these paths, and in particular cargo asm:
pacak/cargo-show-asm#382

Meta

rustc --version --verbose:

rustc 1.85.0 (4d91de4e4 2025-02-17)
binary: rustc
commit-hash: 4d91de4e48198da2e33413efdcd9cd2cc0c46688
commit-date: 2025-02-17
host: aarch64-apple-darwin
release: 1.85.0
LLVM version: 19.1.7

Also tried in

$ rustc +nightly --version --verbose                              
rustc 1.87.0-nightly (e16a049ad 2025-03-03)
binary: rustc
commit-hash: e16a049adbf94d610787430b6efdf31d896dc5b6
commit-date: 2025-03-03
host: aarch64-apple-darwin
release: 1.87.0-nightly
LLVM version: 20.1.0

[bjorn3]

/rustc/e71f9a9a98b0faf423844bf0ba7438f29dc27d58\library\std\src\rt.rs is the actual path that is encoded in the debuginfo. If not for rustc getting compiled with remap-path-prefix, you would have seen a path like C:\path\to\library\std\src\rt.rs. The debuginfo paths reflect the path on the system where the respective crate was compiled. They are likely to be unavailable if you take the compiled crate to another system.

[pacak]

They are likely to be unavailable if you take the compiled crate to another system.

Actual file name may differ, this is fine as long as the file name encoding is correct.

With /rustc/e71f9a9a98b0faf423844bf0ba7438f29dc27d58/library/std/src/rt.rs the logic is relatively simple: does this file exist? - if yes - this is our file. If not - do we recognize the prefix? /rustc/ is a known prefix so we replace first two components of the path with whatever sysroot rustc gives and as long as rust sources component is installed - the file should be there.

Mix of slashes makes this process harder and more fragile.

Does it make sense to make it to emit something like this $RUST_SRC/library/std/src/rt.rs where slashes are all correct? Parsing this would be easier.

https://xkcd.com/1172/