DWARF information does not contain absolute file locations for generics

STR (on Linux):

Create hey.rs file that has generics usage (wget https://raw.githubusercontent.com/yurydelendik/old-man-sandbox/master/rust-wasm-hey/hey.rs)
Compile code rustc +nightly hey.rs --crate-type=cdylib -g -o hey
Dump DWARF info llvm-dwarfdump hey -debug-info -debug-line > hey.txt

Notice that hey.txt contains such entries as DW_AT_decl_file ("/home/yury/liballoc/vec.rs"), possibly produced by the fact that "liballoc/vec.rs" is a relative path and DW_AT_comp_dir is set to "/home/yury".

It is expected for core files to have absolute path e.g. "/rustc/20dc0c50704ba1fc8c56a88ae2bf05ddb3e419bc/src/liballoc/raw_vec.rs"

@michaelwoerister

cc @michaelwoerister @tromey I wonder what interaction (path rewriting?) causes this result.

FWIW, rustc +nightly hey.rs --crate-type=cdylib -g --emit=llvm-ir -o hey.ll produces hey.ll that shows that !DIFile entries has the directory field empty (and the filename is relative)

It is a regression, since +stable has absolute locations, e.g. !47 = !DIFile(filename: "/Users/travis/build/rust-lang/rust/src/libcore/ptr.rs", directory: "")

@alexcrichton

@alexcrichton, could this have to do with #53829?

Likely so! I'll try to look into this in the near future

@michaelwoerister

Ok so the change here can be exhibited with this script:

set -e

cat > foo.rs <<-EOF
#![crate_type = "lib"]
#[inline]
pub fn foo() {}
EOF

cat > bar.rs <<-EOF
#![crate_type = "cdylib"]
extern crate foo;
#[no_mangle]
pub extern fn bar() { foo::foo() }
EOF

rm -rf tmp
mkdir tmp
rustc -g foo.rs --out-dir tmp --remap-path-prefix=`pwd`=/another
rustc -g bar.rs --out-dir tmp -L tmp --emit llvm-ir

rg DIFile tmp/bar.ll

If you execute that script you see:

33:!1 = !DIFile(filename: "bar.rs", directory: "/home/alex/code/rust3")
37:!5 = !DIFile(filename: "foo.rs", directory: "")

but if you remove --remap-path-prefix you see:

33:!1 = !DIFile(filename: "bar.rs", directory: "/home/alex/code/rust3")
37:!5 = !DIFile(filename: "/home/alex/code/rust3/foo.rs", directory: "")

It appears that if upstream crates (like libstd) use --remap-path-prefix then their filename is listed as the original relative source file instead of the absolute path name that it had previous to #53829 when it wasn't compiled with --remap-path-prefix.

So somehow using --remap-path-prefix to compile libstd is affecting downstream crates to have relative path names instead of old absolute path names. It makes sense to me that the absolute path name goes away with --remap-path-prefix (that is the whole point after all) but ideally it'd still be an absolute path, just applying the mapping.

@michaelwoerister would you be able to help point me in the direction of where this change in logic might happen? If so I can test out a patch!

@alexcrichton

@alexcrichton This should be what you're looking for:

rust/src/librustc_metadata/encoder.rs

Lines 352 to 358 in e999ebd

    
           // When exporting SourceFiles, we expand all paths to absolute 
        
           // paths because any relative paths are potentially relative to 
        
           // a wrong directory. 
        
           // However, if a path has been modified via 
        
           // `--remap-path-prefix` we assume the user has already set 
        
           // things up the way they want and don't touch the path values 
        
           // anymore.

One solution would be to compile libstd with absolute paths and apply proper remapping to those.

Ah that's perfect! I'll see if I can work up a solution to that soon

rustc: Tweak filenames encoded into metadata

Rollup merge of rust-lang#54626 - alexcrichton:dwarf-generics, r=mich…

Auto merge of #54626 - alexcrichton:dwarf-generics, r=michaelwoerister

Navigation Menu

Repository navigation

DWARF information does not contain absolute file locations for generics #54408

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	// When exporting SourceFiles, we expand all paths to absolute
	// paths because any relative paths are potentially relative to
	// a wrong directory.
	// However, if a path has been modified via
	// `--remap-path-prefix` we assume the user has already set
	// things up the way they want and don't touch the path values
	// anymore.

DWARF information does not contain absolute file locations for generics #54408

Description

Activity

eddyb commented on Sep 25, 2018

yurydelendik commented on Sep 25, 2018

yurydelendik commented on Sep 25, 2018

michaelwoerister commented on Sep 25, 2018

alexcrichton commented on Sep 26, 2018

alexcrichton commented on Sep 26, 2018

michaelwoerister commented on Sep 27, 2018

alexcrichton commented on Sep 27, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions