Skip to content

[DWARF] Crate Debug Info incomplete? #88521

Closed
@ayermolo

Description

@ayermolo

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.

High level summary:

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 .debug_info.dwo section. They are either exactly the same, or differ by DW_AT_linkage_name.
Although LLVM can be changed to include DW_AT_linkage_name as part of the hashing algorithm, it won't solve the issue fully.

Tools like BOLT (https://github.com/facebookincubator/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

dwo_id (unit ID)
An 8-byte implementation-defined integer constant value, known as the compilation unit ID, that provides unique identification of a skeleton compilation unit and its associated split compilation unit in the object file named in the DW_AT_dwo_name attribute of the skeleton compilation.

Digging a bit in to it:

Looking in to one of the cases where only difference was DW_AT_linkage_name.
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:

!74 = distinct !DISubprogram(name: "allocate_in<u8,alloc::alloc::Global>", linkageName: "_RNvMs_NtCsj2IQpe5qjeI_5alloc7raw_vecINtB4_6RawVechE11allocate_inCsg6LRvGNwJvd_41foo_bar", scope: !76, file: !75, line: 180, type: !96, scopeLine: 180, flags: DIFlagPrototyped, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition | DISPFlagOptimized, unit: !43, templateParams: !94, retainedNodes: !98)
!75 = !DIFile(filename: "<>/rust/1.53.0/src/<>/build/rust/library/alloc/src/raw_vec.rs", directory: "", checksumkind: CSK_MD5, checksum: "70792e0964fbcac42a3928c645b54f9d")
!76 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "RawVec<u8, alloc::alloc::Global>", scope: !53, file: !2, size: 128, align: 64, elements: !77, templateParams: !94, identifier: "900af9eff81db06f40b139cda685ab1")

We have a function:
alloc_in that is part of templated raw_vec
https://doc.rust-lang.org/src/alloc/raw_vec.rs.html#188
https://doc.rust-lang.org/src/alloc/raw_vec.rs.html#115

From LinkageName this is relavant?
pub mod bar { pub use foo_bar::*; }

In a different module it will have:

!74 = distinct !DISubprogram(name: "allocate_in<u8,alloc::alloc::Global>", linkageName: "_RNvMs_NtCsj2IQpe5qjeI_5alloc7raw_vecINtB4_6RawVechE11allocate_inCskK341NkcZ13_41foo_bar2", scope: !76, file: !75, line: 180, type: !96, scopeLine: 180, flags: DIFlagPrototyped, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition | DISPFlagOptimized, unit: !43, templateParams: !94, retainedNodes: !98)
!75 = !DIFile(filename: "<>/rust/1.53.0/src/<>/build/rust/library/alloc/src/raw_vec.rs", directory: "", checksumkind: CSK_MD5, checksum: "70792e0964fbcac42a3928c645b54f9d")
!76 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "RawVec<u8, alloc::alloc::Global>", scope: !53, file: !2, size: 128, align: 64, elements: !77, templateParams: !94, identifier: "900af9eff81db06f40b139cda685ab1")

and on rust side:
pub mod bar2 { pub use foo_bar2::*; }

I haven't looked in to cases where debug information is identical, beyond that it didn't have any functions just type information {DW_TAG_namespace , DW_TAG_enumeration_type , DW_TAG_enumerator}.

To me it seems that there is debug information missing on some level that represents what crate this CU belongs.
Any thoughts?

Metadata

Metadata

Assignees

Labels

A-debuginfoArea: Debugging information in compiled programs (DWARF, PDB, etc.)C-bugCategory: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions