Fails to find source file when cross-compiling due to mixed slashes

[evmar]

From a Mac, cross-compiling to Windows:

$ cargo-asm -vvv -p x86 --target i586-pc-windows-msvc --rust mov_r8_rm8
[...]
Artifact files: ["/Users/evmar/win/rs/target/i586-pc-windows-msvc/release/libx86.rlib", "/Users/evmar/win/rs/target/i586-pc-windows-msvc/release/deps/libx86-4448cbf56d50bb97.rmeta"]
Working with file: /Users/evmar/win/rs/target/i586-pc-windows-msvc/release/deps/x86-4448cbf56d50bb97.s
goal: Function { function: "mov_r8_rm8", nth: None }
Reading file #1 /rustc/e71f9a9a98b0faf423844bf0ba7438f29dc27d58\library\core\src\fmt\mod.rs
Resolved name is "/Users/evmar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/src/rust"
thread 'main' panicked at src/asm.rs:545:70:
Can't read a file: Os { code: 21, kind: IsADirectory, message: "Is a directory" }
stack backtrace:
   0: rust_begin_unwind
             at /rustc/e71f9a9a98b0faf423844bf0ba7438f29dc27d58/library/std/src/panicking.rs:665:5
   1: core::panicking::panic_fmt
             at /rustc/e71f9a9a98b0faf423844bf0ba7438f29dc27d58/library/core/src/panicking.rs:76:14
   2: core::result::unwrap_failed
             at /rustc/e71f9a9a98b0faf423844bf0ba7438f29dc27d58/library/core/src/result.rs:1699:5
   3: core::result::Result<T,E>::expect
             at /Users/evmar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/src/rust/library/core/src/result.rs:1061:23
   4: cargo_show_asm::asm::load_rust_sources::{{closure}}
             at /Users/evmar/projects/cargo-show-asm/src/asm.rs:545:35
   5: alloc::collections::btree::map::entry::Entry<K,V,A>::or_insert_with
             at /Users/evmar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/src/rust/library/alloc/src/collections/btree/map/entry.rs:186:43
   6: cargo_show_asm::asm::load_rust_sources
             at /Users/evmar/projects/cargo-show-asm/src/asm.rs:535:13

Breaking that down, it's trying to read the file /rustc/e71f9a9a98b0faf423844bf0ba7438f29dc27d58\library\core\src\fmt\mod.rs but it locate_sources resolves that a directory, not a file.

The underlying .s file it's parsing (/Users/evmar/win/rs/target/i586-pc-windows-msvc/release/deps/x86-4448cbf56d50bb97.s) has lines like

	.cv_file	1 "/rustc/e71f9a9a98b0faf423844bf0ba7438f29dc27d58\\library\\core\\src\\fmt\\mod.rs" "CB10D2393147BBE2E6E2C7BA87780A31E25E38C1314E90CE707570F48CD417D9" 3

so I guess the mixed-slash paths are generated by the Rust toolchain(?).

It looks like locate_sources uses Path::components, which uses platform-local path splitting.

Possibly related to #215, but I think if you're running on actual Windows all the path splitting and file lookups are designed to succeed.

[evmar]

Now that I've typed that all out, possibly the right answer is that these .cv_file bits generated from Rust are just wrong and this should be fixed there.

[evmar]

Workaround: use a target with the same assembly syntax but with the host system so the paths are sane, e.g. x86_64-apple-darwin on Mac.

[pacak]

Now that I've typed that all out, possibly the right answer is that these .cv_file bits generated from Rust are just wrong and this should be fixed there.

Yay to rubber duck debugging. .cv_file indeed looks wrong - \\library\\core\\src\\fmt\\mod.rs is a perfectly valid file name. Are you planning to make a ticket upstream? I could try making some horrible workaround meanwhile...

[pacak]

I pushed a branch called cursed, can you check if it solves your problem?

[evmar]

Yes, that branch works. I would like to make a ticket upstream, let me see if I can reduce it into anything useful.

[evmar]

Given my current workaround is adequate, I think I would leave out your cursed patch (unless upstream thinks this is unfixable, maybe).