`--remap-path-prefix FROM=TO` creates invalid paths if `TO` doesn't start with `/`

[xobs]

The documentation for rustc describes the --remap-path-prefix option as:

        --remap-path-prefix FROM=TO
                        Remap source names in all output (compiler messages
                        and output files)

This appears to only work if TO begins with /. Otherwise, it seems to sometimes miss the remapping.

For example, let's set up a test case with no remapping that only logs a message using the log crate:

$ mkdir remap-example
$ cd remap-example/
$ cargo init
    Creating binary (application) package
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
$ cargo add -q log
$ echo 'fn main() { log::info!("Hello, world!"); }' > src/main.rs
$ cargo +nightly build
   Compiling log v0.4.25
   Compiling remap-example v0.1.0 (/opt/Xous/remap-example)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.30s
$ llvm-dwarfdump-15 --show-sources target/debug/remap-example | grep log
/home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/log-0.4.25/src/__private_api.rs
/home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/log-0.4.25/src/lib.rs
/rustc/a567209daab72b7ea59eac533278064396bb0534/library/core/src/num/int_log10.rs
$

If this is built with the replacement directory as example, it works:

$ RUSTFLAGS=--remap-path-prefix=/home/user/.cargo/registry/src=/example cargo +nightly
 build
   Compiling log v0.4.25
   Compiling remap-example v0.1.0 (/opt/Xous/remap-example)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.37s
$ llvm-dwarfdump-15 --show-sources target/debug/remap-example | grep log
/example/index.crates.io-1949cf8c6b5b557f/log-0.4.25/src/__private_api.rs
/example/index.crates.io-1949cf8c6b5b557f/log-0.4.25/src/lib.rs
/rustc/a567209daab72b7ea59eac533278064396bb0534/library/core/src/num/int_log10.rs
$

However, if the replacement path becomes example (without the leading /) it does something funny:

$ RUSTFLAGS=--remap-path-prefix=/home/user/.cargo/registry/src=example cargo +nightly build
   Compiling log v0.4.25
   Compiling remap-example v0.1.0 (/opt/Xous/remap-example)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.32s
$ llvm-dwarfdump-15 --show-sources target/debug/remap-example | grep log
/opt/Xous/remap-example/example/index.crates.io-1949cf8c6b5b557f/log-0.4.25/src/__private_api.rs
/opt/Xous/remap-example/example/index.crates.io-1949cf8c6b5b557f/log-0.4.25/src/lib.rs
/rustc/a567209daab72b7ea59eac533278064396bb0534/library/core/src/num/int_log10.rs
example/index.crates.io-1949cf8c6b5b557f/log-0.4.25/src/__private_api.rs
example/index.crates.io-1949cf8c6b5b557f/log-0.4.25/src/lib.rs
$

Notice how it created a second copy of the entries in the current directory, in addition to performing the replacement.

Meta

rustc --version --verbose:

rustc 1.86.0-nightly (a567209da 2025-02-13)
binary: rustc
commit-hash: a567209daab72b7ea59eac533278064396bb0534
commit-date: 2025-02-13
host: x86_64-unknown-linux-gnu
release: 1.86.0-nightly
LLVM version: 19.1.7

[xobs]

This seems partially a problem with LLVM, but it may involve how rust is interacting with it.

For example, if I change

rust/compiler/rustc_codegen_llvm/src/debuginfo/metadata.rs

Line 579 in 6d3c050

("".into(), abs_path.to_string_lossy().into_owned())

:

diff --git a/compiler/rustc_codegen_llvm/src/debuginfo/metadata.rs b/compiler/rustc_codegen_llvm/src/debuginfo/metadata.rs
index 98d59f5a8ae..e0cdecb3924 100644
--- a/compiler/rustc_codegen_llvm/src/debuginfo/metadata.rs
+++ b/compiler/rustc_codegen_llvm/src/debuginfo/metadata.rs
@@ -576,7 +583,7 @@ fn alloc_new_file_metadata<'ll>(
                             rel_path.to_string_lossy().into_owned(),
                         )
                     } else {
-                        ("".into(), abs_path.to_string_lossy().into_owned())
+                        ("/".into(), abs_path.to_string_lossy().into_owned())
                     }
                 } else {
                     let working_directory = working_directory.local_path_if_available();

...then the resulting output looks like this:

/example/index.crates.io-1949cf8c6b5b557f/log-0.4.25/src/__private_api.rs
/example/index.crates.io-1949cf8c6b5b557f/log-0.4.25/src/lib.rs
/opt/osdyne/rust/library/core/src/num/int_log10.rs
example/index.crates.io-1949cf8c6b5b557f/log-0.4.25/src/__private_api.rs
example/index.crates.io-1949cf8c6b5b557f/log-0.4.25/src/lib.rs

So something inside llvm is prefixing the (current working directory?). But only sometimes.

[xobs]

The problem is partially due to how the DWARF specification is written. From https://dwarfstd.org/doc/DWARF5.pdf :

A full or partial compilation unit entry may have the following attributes:
...
2. A DW_AT_name attribute whose value is a null-terminated string containing
the full or relative path name (relative to the value of the DW_AT_comp_dir
attribute, see below) of the primary source file from which the compilation
unit was derived.

The issue is that if the path isn't absolute, then the debugger can't know whether or not to prefix the compilation unit's path onto the file path, so it will always do so. And since files within a crate may reference other crates with different paths, it can't know whether to prefix the path or not.