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.