Change:
Hello. To preface this. I know nothing about RUST and its compiler. I am coming to this issue on toolchain side BOLT/DWP and dealing with debug information that is produced. I am seeing multiple Skeleton CUs that have exact same DWO ID. So for example with ThinLTO when Split dwarf is enabled in main binary there are multiple CUs that point to different .dwo files, but have the same DWO ID. Looking in to those files in to section. They are either exactly the same, or differ by DWATlinkagename. Although LLVM can be changed to include DWATlinkagename as part of the hashing algorithm, it won't solve the issue fully. Tools like BOLT (), or llvm-dwp rely on DWO ID to be unique. From DWARF 5 spec (when this was all standardized), but I think also applies to DWARF4 Looking in to one of the cases where only difference was DWATlinkagename. There are multiple modules, crates in rust land?, that are created. They define the same templated functions, and import the same functions. For example looking at LLVM IR of one of the modules and one of the functions: We have a function: allocin that is part of templated rawvec From LinkageName this is relavant? pub mod bar { pub use foobar::; } In a different module it will have: and on rust side: pub mod bar2 { pub use foobar2::; } I haven't looked in to cases where debug information is identical, beyond that it didn't have any functions just type information {DWTAGnamespace , DWTAGenumerationtype , DWTAG_enumerator}. To me it seems that there is debug information missing on some level that represents what crate this CU belongs. Any thoughts?
I'm not familiar with debuginfo generation - you'll probably get a more prompt response if you ask in T-compiler on Zulip: https://rust-
I'm curious though why this has never come up before? It sounds like a lot of tools depend on this.
Ok, I'll ask there. No idea. As I said I am not familiar with Rust and just dealing with it's output on tools side of things. So any tips and whatnot are appreciated. Maybe my understanding of what's happening is completely wrong.
Note that modules, crates, and codegen units are all different. "Modules" in Rust only affect privacy, they don't affect codegen (it sounds like you were treating LLVM modules the same as Rust modules above, and they're not the same). "Crates" are "codegen units for the rust compiler", they're all compiled at once and there's various things you can do within a crate that you can't do outside it (e.g. implement traits for a type). But the rust compiler will often split up crates into multiple LLVM codegen units before passing them to LLVM, so that it can cache them more often:
Can you give info on how to reproduce the problem? It sounds like you are using which is unstable and probably not widely tested. As a wild guess, maybe helps? That doesn't sound like something that DWARF consumers should ever need to know.
Thanks for clarification. Let me poke around internally, and read up on rust to see if I can come up with small reproducer.
Here's a reproduction using the xtask crate within rust-analyzer ( with and to ). <details<summaryThe executable has 4 skeleton units pointing to the same .dwo:</summary</detailsNote that none of these contain any definitions with addresses. And contains 4 identical with that . <details<summaryHere's one of them:</summary</detailsI'm guessing those 4 units aren't really meant to be identical, so the duplicate DWO id is causing some to be lost. A reason for that is I think the full units are meant to have entries that correspond to the in the skeleton units. Disabling LTO or using thin LTO works okay in this instance.
(which is a workaround for ) also works around this bug when using fat LTO, because now there is only one CU so there can't be duplicates. It won't affect thin LTO though, and I still don't have a reproduction for that.
Sorry didn't get a chance to get to this before PTO. I asked someone to do it internally, if not I'll priorities once I get back.

Discussion:
None => PathBuf::from(&*tcx.crate_name(LOCAL_CRATE).as_str()), }; <del> // 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 is harmless. if tcx.sess.target.is_like_osx { name_in_debuginfo.push("@"); name_in_debuginfo.push(codegen_unit_name); } </del> <ins> // To avoid breaking split DWARF, we need to ensure that each codegen unit // has a unique `DW_AT_name`. This is because there's a remote chance that // different codegen units for the same module will have entirely // identical DWARF entries for the purpose of the DWO ID, which would // violate Appendix F ("Split Dwarf Object Files") of the DWARF 5 // specification. LLVM uses the algorithm specified in section 7.32 "Type // Signature Computation" to compute the DWO ID, which does not include // any fields that would distinguish compilation units. So we must embed // the codegen unit name into the `DW_AT_name`. (Issue #88521.) // // Additionally, 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 for these two issues, we generate unique names for each // object file. Those do not correspond to an actual source file but that // is harmless. name_in_debuginfo.push("@"); name_in_debuginfo.push(codegen_unit_name); </ins> debug!("compile_unit_metadata: {:?}", name_in_debuginfo); let rustc_producer =