Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--remap-path-prefix not remapping out_dir in debug info on Wasm #80776

Closed
alecmocatta opened this issue Jan 7, 2021 · 6 comments
Closed

--remap-path-prefix not remapping out_dir in debug info on Wasm #80776

alecmocatta opened this issue Jan 7, 2021 · 6 comments
Labels
A-reproducibility Area: Reproducible / deterministic builds C-bug Category: This is a bug. O-wasm Target: WASM (WebAssembly), http://webassembly.org/ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@alecmocatta
Copy link
Contributor

I'm seeing an un-remapped path in a Wasm bin compiled with --target=wasm32-unknown-unknown --release debug = 1 --remap-path-prefix=$CARGO_MANIFEST_DIR= on nightly-2021-01-02. Here's a snippet of it and a couple of preceding strings that help contextualise:

\0clang LLVM (rustc version 1.51.0-nightly (17eec1433 2021-01-01))\0frontend/src/lib.rs\0/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps\0

It looks like it's the out_dir that's not getting remapped:

pub fn compile_unit_metadata(
tcx: TyCtxt<'_>,
codegen_unit_name: &str,
debug_context: &CrateDebugContext<'ll, '_>,
) -> &'ll DIDescriptor {
let mut name_in_debuginfo = match tcx.sess.local_crate_source_file {
Some(ref path) => path.clone(),
None => PathBuf::from(&*tcx.crate_name(LOCAL_CRATE).as_str()),
};
// The OSX linker has an idiosyncrasy where it will ignore some debuginfo
// if multiple object files with the same `DW_AT_name` are linked together.
// As a workaround we generate unique names for each object file. Those do
// not correspond to an actual source file but that should be harmless.
if tcx.sess.target.is_like_osx {
name_in_debuginfo.push("@");
name_in_debuginfo.push(codegen_unit_name);
}
debug!("compile_unit_metadata: {:?}", name_in_debuginfo);
let rustc_producer =
format!("rustc version {}", option_env!("CFG_VERSION").expect("CFG_VERSION"),);
// FIXME(#41252) Remove "clang LLVM" if we can get GDB and LLVM to play nice.
let producer = format!("clang LLVM ({})", rustc_producer);
let name_in_debuginfo = name_in_debuginfo.to_string_lossy();
let flags = "\0";
let out_dir = &tcx.output_filenames(LOCAL_CRATE).out_directory;
let split_name = tcx
.output_filenames(LOCAL_CRATE)
.split_dwarf_filename(tcx.sess.opts.debugging_opts.split_dwarf, Some(codegen_unit_name))
.unwrap_or_default();
let out_dir = out_dir.to_str().unwrap();
let split_name = split_name.to_str().unwrap();
// FIXME(#60020):
//
// This should actually be
//
// let kind = DebugEmissionKind::from_generic(tcx.sess.opts.debuginfo);
//
// That is, we should set LLVM's emission kind to `LineTablesOnly` if
// we are compiling with "limited" debuginfo. However, some of the
// existing tools relied on slightly more debuginfo being generated than
// would be the case with `LineTablesOnly`, and we did not want to break
// these tools in a "drive-by fix", without a good idea or plan about
// what limited debuginfo should exactly look like. So for now we keep
// the emission kind as `FullDebug`.
//
// See https://github.com/rust-lang/rust/issues/60020 for details.
let kind = DebugEmissionKind::FullDebug;
assert!(tcx.sess.opts.debuginfo != DebugInfo::None);
unsafe {
let file_metadata = llvm::LLVMRustDIBuilderCreateFile(
debug_context.builder,
name_in_debuginfo.as_ptr().cast(),
name_in_debuginfo.len(),
out_dir.as_ptr().cast(),
out_dir.len(),
llvm::ChecksumKind::None,
ptr::null(),
0,
);
let unit_metadata = llvm::LLVMRustDIBuilderCreateCompileUnit(
debug_context.builder,
DW_LANG_RUST,
file_metadata,
producer.as_ptr().cast(),
producer.len(),
tcx.sess.opts.optimize != config::OptLevel::No,
flags.as_ptr().cast(),
0,
split_name.as_ptr().cast(),
split_name.len(),
kind,
0,
tcx.sess.opts.debugging_opts.split_dwarf_inlining,
);
if tcx.sess.opts.debugging_opts.profile {
let cu_desc_metadata =
llvm::LLVMRustMetadataAsValue(debug_context.llcontext, unit_metadata);
let default_gcda_path = &tcx.output_filenames(LOCAL_CRATE).with_extension("gcda");
let gcda_path =
tcx.sess.opts.debugging_opts.profile_emit.as_ref().unwrap_or(default_gcda_path);
let gcov_cu_info = [
path_to_mdstring(
debug_context.llcontext,
&tcx.output_filenames(LOCAL_CRATE).with_extension("gcno"),
),
path_to_mdstring(debug_context.llcontext, &gcda_path),
cu_desc_metadata,
];
let gcov_metadata = llvm::LLVMMDNodeInContext(
debug_context.llcontext,
gcov_cu_info.as_ptr(),
gcov_cu_info.len() as c_uint,
);
let llvm_gcov_ident = const_cstr!("llvm.gcov");
llvm::LLVMAddNamedMetadataOperand(
debug_context.llmod,
llvm_gcov_ident.as_ptr(),
gcov_metadata,
);
}
// Insert `llvm.ident` metadata on the wasm32 targets since that will
// get hooked up to the "producer" sections `processed-by` information.
if tcx.sess.opts.target_triple.triple().starts_with("wasm32") {
let name_metadata = llvm::LLVMMDStringInContext(
debug_context.llcontext,
rustc_producer.as_ptr().cast(),
rustc_producer.as_bytes().len() as c_uint,
);
llvm::LLVMAddNamedMetadataOperand(
debug_context.llmod,
const_cstr!("llvm.ident").as_ptr(),
llvm::LLVMMDNodeInContext(debug_context.llcontext, &name_metadata, 1),
);
}
return unit_metadata;
};
fn path_to_mdstring(llcx: &'ll llvm::Context, path: &Path) -> &'ll Value {
let path_str = path_to_c_string(path);
unsafe {
llvm::LLVMMDStringInContext(
llcx,
path_str.as_ptr(),
path_str.as_bytes().len() as c_uint,
)
}
}
}

@alecmocatta alecmocatta added the C-bug Category: This is a bug. label Jan 7, 2021
@nagisa
Copy link
Member

nagisa commented Jan 8, 2021

Are you passing $CARGO_MANIFEST_DIR as an argument verbatim (that probably won't work, rustc won't expand arguments)? Can you post the arguments that the invocation of rustc receives?

(Doing so may involve suspending the execution of rustc and then obtaining the CLI through operating system; e.g. on Linux via cat /proc/<PID>/cmdline)

@alecmocatta
Copy link
Contributor Author

alecmocatta commented Jan 8, 2021

RUSTFLAGS='--remap-path-prefix=/Users/alec/Documents/frontend= --remap-path-prefix=/Users/alec/.rustup/toolchains/nightly-x86_64-apple-darwin= --remap-path-prefix=/Users/alec/.cargo/registry/src=' cargo build --package=frontend --lib --target=wasm32-unknown-unknown -Z build-std=std,panic_abort --release --verbose:

rustc --crate-name frontend --edition=2018 frontend/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type cdylib --emit=dep-info,link -C opt-level=3 -C panic=abort -C embed-bitcode=no -C debuginfo=1 -C overflow-checks=on -C metadata=d690439610fd46ff --out-dir /Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps --target wasm32-unknown-unknown -L dependency=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps -L dependency=/Users/alec/Documents/frontend/target/release/deps --extern 'noprelude:alloc=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/liballoc-21064f837a6ce201.rlib' --extern base64=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libbase64-d1417908bb5c991a.rlib --extern borsh=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libborsh-3a9a2179b6181e6f.rlib --extern bytesize=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libbytesize-ff41001dae3d81ae.rlib --extern common=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libcommon-120bd5d92e90e191.rlib --extern 'noprelude:compiler_builtins=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libcompiler_builtins-cc4855d60cdc44b7.rlib' --extern 'noprelude:core=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libcore-4ca9d146743d88a5.rlib' --extern derive_new=/Users/alec/Documents/frontend/target/release/deps/libderive_new-0a543881a2243fda.dylib --extern either=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libeither-cda7cc04043eb3d8.rlib --extern futures=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libfutures-7fb6fe532f8cdb65.rlib --extern futures_intrusive=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libfutures_intrusive-ec48330797918ba3.rlib --extern instant=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libinstant-8208dddaac005592.rlib --extern js_sys=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libjs_sys-000cf2ac132253e4.rlib --extern maplit=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libmaplit-69a523e37d42b692.rlib --extern num=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libnum-f3858087148fee1b.rlib --extern 'noprelude:panic_abort=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libpanic_abort-6540aba0ce5a9639.rlib' --extern 'noprelude:panic_unwind=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libpanic_unwind-72b206be10100e2c.rlib' --extern pin_cell=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libpin_cell-a19be411f419a79a.rlib --extern pin_project=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libpin_project-88db610adffc8c4d.rlib --extern pin_weak=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libpin_weak-a31cc3784bfeaa2a.rlib --extern 'noprelude:proc_macro=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libproc_macro-4786600990539276.rlib' --extern pulldown_cmark=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libpulldown_cmark-b92e78ac485ec452.rlib --extern replace_with=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libreplace_with-2ef477612fd10f0d.rlib --extern 'noprelude:std=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libstd-ead026bacacd2c67.rlib' --extern wasm_bindgen=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libwasm_bindgen-7ae4d872bfb78bb4.rlib --extern wasm_bindgen_futures=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libwasm_bindgen_futures-f94a2d9aa3aa1b5b.rlib --extern wasm_timer=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libwasm_timer-33965abb275568e6.rlib --extern web_sys=/Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps/libweb_sys-827dafb5b53a5b12.rlib -Z unstable-options --remap-path-prefix=/Users/alec/Documents/frontend= --remap-path-prefix=/Users/alec/.rustup/toolchains/nightly-x86_64-apple-darwin= --remap-path-prefix=/Users/alec/.cargo/registry/src=

All other paths are successfully remapped so I'm not sure it's related to the argument getting to rustc? It's literally just /Users/alec/Documents/frontend/target/wasm32-unknown-unknown/release/deps that is not remapped.

@nagisa
Copy link
Member

nagisa commented Jan 8, 2021

Yeah, I just wanted to make sure it is not something obviously wrong with how arguments get to rustc, especially as you mentioned use of environment variables, that are typically set inside cargo.

@nagisa
Copy link
Member

nagisa commented Feb 14, 2021

This might be fixed by #82102 as well.

@nagisa nagisa added A-reproducibility Area: Reproducible / deterministic builds T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 14, 2021
@jyn514
Copy link
Member

jyn514 commented May 19, 2021

#82102 was merged, are you still running into this?

@alecmocatta
Copy link
Contributor Author

Confirmed I'm no longer seeing this bug. Thanks both, closing!

@jieyouxu jieyouxu added the O-wasm Target: WASM (WebAssembly), http://webassembly.org/ label Aug 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-reproducibility Area: Reproducible / deterministic builds C-bug Category: This is a bug. O-wasm Target: WASM (WebAssembly), http://webassembly.org/ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants