Metaissue for Visual Studio debugging Rust

[sophiajt]

Recently, I started playing with the new VS 2017 Community edition. Specifically, I wanted to see if Rust debugging works with VS. Good news: out of the box, you can attach to running Rust applications compiled in debug mode, pause them, and begin debugging.

The experience isn't perfect, and I hope to grow this issue to include the places where the experience can be improved.

• u8/i8 are not shown in debugger (i8 and u8 not correctly shown in MSVC debugger #36646)
• std lib needs visualisers for std structs like String, Vec etc. WIP effort (though Vec, LinkedList, VecDeque, String, and Option NatVis visualizations #39843 looks better)
• &str isn't understood by VS (can't natvis)
• watches for shadowed variables confuse VS

[Boddlnagg]

There was some previous work trying to use natvis: #36503

Notably, the following natvis code enables the VS "Text Visualizer" for strings, using the correct UTF-8 encoding (at least this worked in VS 2015):

  <Type Name="collections::string::String">
    <DisplayString>{vec.buf.ptr.pointer.__0, [vec.len]s8}</DisplayString>
    <StringView>vec.buf.ptr.pointer.__0, [vec.len]s8</StringView>
  </Type>

[sophiajt]

@Boddlnagg - I noticed that only works if you have patched s8 support? I tried just copying/pasting your example with out and wasn't able to get it to work.

I also noticed that #39843 is related to the natvis work.

[Boddlnagg]

@jonathandturner I did not patch s8 support (I don't even know what you mean by that) ... but I had to manually work around #36646 by patching the type information in the PDB.

I'd also like to point out that #36503 (comment) explains the ability to embed natvis files into PDBs (maybe rustc could do that automatically at some point).

[codec-abc]

I think that if it is possible, conditional breakpoints would be a nice addition.

[mzji]

rustc/cargo don't copy the .pdb file to the directory of the executable automatically anymore, is that a decision/design of rustc/cargo? IIRC rustc 1.13 will copy the .pdb file.

[retep998]

@mzji The .exe or .dll has the absolute path to the .pdb hardcoded so the debugger can still find the .pdb even if you moved the .exe or .dll.

[mzji]

@retep998 So if the debugger failed to load the .pdb files automatically, does that means there is a bug in the debugger?

Here is the log when I try to debug my new project with x64dbg:

SYMSRV:  C:\Users\admin\Documents\x64dbg\x64\symbols\vs2017detect-18f12543191b1f33.pdb\98880B4BE9AF44E5A205282AEBB1C814d\vs2017detect-18f12543191b1f33.pdb not found
DBGHELP: C:\Users\admin\Documents\vs2017detect\target\debug\vs2017detect-18f12543191b1f33.pdb - file not found
...(unrelated part eliminated)

After failed loading from the symbol cache, x64dbg just tries to load the file from the working directory of the executable. And the DBGHELP part made me believe that x64dbg is using some windows system library to do this. Is there a bug in the debugger, or this behavior is just what windows will do?

[lnicola]

@mzji I think VS loads the PDB, but in VS Code I had to change the launch configuration to run the executable from the deps folder (with the PDB next to it). I would have expected WinDbg to behave just like VS does, though.

[mzji]

@lnicola Then I think we should at least leave a copy in the directory of binaries, since different debuggers do different things (VS will find and load pdb files automatically, VS Code/Ollydbg/x64dbg and all debuggers which is only using DBGHELP won't).

[codec-abc]

Back to the original issues, the most 2 annoying things that happen when I try to debug Servo is that:

• Breakpoints are hit multiple times per line in some cases.
• Enums values are not understood in the "local" inspector. This is annoying since most Rust code use heavily Option and Result.

[sophiajt]

@codec-abc - by chance, have you tried using the natvis from this PR to see if it helps with your second bullet point? #39843

I've been chatting with the author and would like to potentially make it part of the pdb at some point.

[codec-abc]

I used the one in the opening message of the issue. So they are probably different.

Edit : Damned the "good" one was just a few characters away. How stupid I am.

[sophiajt]

@codec-abc - yeah, the one in the PR is much better than mine, with support for more common Rust std lib structures.

[MaulingMonkey]

• Fixes for u8/i8 have landed in nightly.
• Some stdlib visualizers have landed in stable.
• I have a hacky changelist I'm working on to enable visualization of &str and array slices (via renaming debug info), and to auto-embed .natvis files into the resulting pdbs for maximum convenience.

[abonander]

@MaulingMonkey's PR brought visualization quite a long way but there's still a few shortcomings in the debugging experience as of the latest nightly:

• Mutable slices need a separate visualizer entry, as their type name is mut slice<*>; I was able to fix this just by duplicating the visualizer entry for slice in intrinsic.natvis:

 <Type Name="slice&lt;*&gt;">
    <DisplayString>{{ length={length} }}</DisplayString>
    <Expand>
      <Item Name="[size]" ExcludeView="simple">length</Item>
      <ArrayItems>
        <Size>length</Size>
        <ValuePointer>data_ptr</ValuePointer>
      </ArrayItems>
    </Expand>
    </Type>
    <!-- added -->
    <Type Name="mut slice&lt;*&gt;">
    <DisplayString>{{ length={length} }}</DisplayString>
    <Expand>
      <Item Name="[size]" ExcludeView="simple">length</Item>
      <ArrayItems>
        <Size>length</Size>
        <ValuePointer>data_ptr</ValuePointer>
      </ArrayItems>
    </Expand>
  </Type>

• Slice visualization works fine in the same stack frame that the slice is created but breaks down when the slice is passed to a function call:

Source frame	Top frame

• Also, you look closely in the screenshot above you can see that the fn main() stack frame is shown at the wrong source line.

(This is VS2017, but it's the same in VS2019.)

[rylev]

There has been progress on this issue from several fronts lately:

• Stop adding '*' at the end of slice and str typenames for MSVC case #79184
• Improvements to NatVis support #80311
• Fix debug information for function arguments of type &str or slice. #81898
• Add natvis for Result, NonNull, CString, CStr, and Cow #82557

Some additional todos/issues:

• Arrays cannot provide custom DisplayStrings
• Option where the option can take advantage of the None == 0 niche not showing in WinDbg
• No debug info for char locals

[pnkfelix]

Visiting for T-compiler backlog bonanza.

After discussion, we think its an anti-pattern to have an issue with an ever-growing list of features that will evolve, especially to match a debugger that is also growing new features over time. (If you want to see all the debugging issues on windows, you can use a github issue query for A-debuginfo and O-windows, or something along those lines.)

So, we think the main focus of this issue should be the four points that were raised in the description (and new issues should be filed to cover new goals).

As for the four points in the description, @wesleywiser says that the first three are fixed today, and believes the fourth to be fixed if you are using Visual Studio 2022.

Closing.