Repository navigation
DWARF information does not contain absolute file locations for generics #54408
Description
Activity
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.llproduces 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, could this have to do with #53829?
Likely so! I'll try to look into this in the near future
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.llIf 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-prefixyou 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-prefixthen 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-prefixto 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 This should be what you're looking for:
rust/src/librustc_metadata/encoder.rs
Lines 352 to 358 in e999ebd
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
- added a commit that references this issue
on Sep 27, 2018 - added a commit that references this issue
on Oct 26, 2018
STR (on Linux):
wget https://raw.githubusercontent.com/yurydelendik/old-man-sandbox/master/rust-wasm-hey/hey.rs)rustc +nightly hey.rs --crate-type=cdylib -g -o heyllvm-dwarfdump hey -debug-info -debug-line > hey.txtNotice 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"