Debuginfo for niche-layout enums can be corrupted due to duplicate type names #84670
Assignees
Labels
A-debuginfo
Area: Debugging information in compiled programs (DWARF, PDB, etc.)
A-layout
Area: Memory layout of types
C-bug
Category: This is a bug.
O-windows-msvc
Toolchain: MSVC, Operating system: Windows
Comments
wesleywiser
added
A-debuginfo
|
@wesleywiser Could you please explain why duplicate names cause this confusion? Aren't PDB types identified by record ids? |
|
@vadimcn I thought that as well but experimentally, the debugger seems to look up the types by name not record id. I've also seen warnings from cvdump related "duplicate/conflicting type definitions" even though the ids are different. I'll post the cvdump results when I get back into the office on Monday. |
|
For example, cvdump outputs this: |
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this issue
Jun 3, 2021
…elwoerister
Improve debugging experience for enums on windows-msvc
This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways:
1. Improves the debugger experience for directly tagged enums.
2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example, `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger.
3. Significantly improves the debugger experience for niche-layout enums.
Let's look at a few examples:
```rust
pub enum CStyleEnum {
Base = 2,
Exponent = 16,
}
pub enum NicheLayoutEnum {
Tag1,
Data { my_data: CStyleEnum },
Tag2,
Tag3,
Tag4,
}
pub enum OtherEnum<T> {
Case1(T),
Case2(T),
}
fn main() {
let a = Some(CStyleEnum::Base);
let b = Option::<CStyleEnum>::None;
let c = NicheLayoutEnum::Tag1;
let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent };
let e = NicheLayoutEnum::Tag2;
let f = Some(&1u32);
let g = Option::<&'static u32>::None;
let h = Some(&2u64);
let i = Option::<&'static u64>::None;
let j = Some(12u32);
let k = Option::<u32>::None;
let l = Some(12.34f64);
let m = Option::<f64>::None;
let n = CStyleEnum::Base;
let o = CStyleEnum::Exponent;
let p = Some("IAMA optional string!".to_string());
let q = OtherEnum::Case1(42u32);
}
```
This is what WinDbg Preview shows using the latest rustc nightly:
Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse, drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types:
With the changes in this PR, we're able to write two natvis definitions that cover all enum cases generally. After building with these changes, WinDbg now shows this instead:
Drilling into the same variables, we can see much more useful information:
Fixes rust-lang#84670
Fixes rust-lang#84671
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Niche layout enum variants do not get distinct type names that include type parameters which can cause duplicate type names for variants like
Option::Some. This in turn will causes debugger to randomly pick one of the various type layouts when inspecting values which can cause invalid results.Notice the values for
a,bandcare totally wrong because they are using the layout forOption<&i64>::Some. The types for the other variables are also wrong but that doesn't happen to cause issues in this particular instance.The text was updated successfully, but these errors were encountered: