Visual Studio Code, Code-D and Microsoft's Visual C++ Debugger (cppvsdbg)

Void-995 void995 at gmail.com
Wed Sep 19 14:22:13 UTC 2018


Good time of day, everyone

Recently I've got myself into D Language again, but got a problem 
with debugging on Windows, obviously. While Visual D with Mago 
provides pretty comfortable workflow, I highly appreciate what 
Code D did with it's more closer and tight integrating with 
DScanner and DFormat, better DUB workflow and so on... The 
biggest problem there is debugging on Windows OS. GDB from either 
Microsoft's C/C++ plugin (ms-vscode.cpptools) or WebFreak's 
Native Debug (webfreak.debug) didn't took me anywhere. Broken 
Mago-MI integration in WebFreak's Native Debug (which I have 
"fixed" locally after few moves around) didn't took me far as 
well, the best I got was something bad about Stack Frame.

Meanwhile, the original Microsoft's Visual C++ Debugger 
(cppvsdbg) is working pretty much flawless with D. With the 
problem, of course, not being able to show what is inside of the 
slice/dynamic arrays. Having "fun" with Natvis (The Visual Studio 
Natvis framework lets you customize the way Visual Studio 
displays native types in debugger variable windows) I found that 
giving D types to catch won't work as Visual C++ Debugger 
(cppvsdbg) is expecting valid C++ names to work with.

I mostly gave up there, but then I found interesting trick that 
Visual Rust and Rust plugin for Visual Studio Code are using. 
They added option to compiler to write debug information as 
that's C++ code (so they doesn't have to come up with their own 
debugger for Windows), with pretty simple trick in rustc and 
simplest Natvis file they then have integrated into PDB that they 
ship with it. So I've tried to apply that to DMD and see what 
will happen.

Currently, as matter of experiment, I've changed it on my side 
permanently, but thinking about adding new flag to DMD. The 
change was about this big:
// --------------------------------
diff --git a/src/dmd/hdrgen.d b/src/dmd/hdrgen.d
index d9eca8721..a02c6bfef 100644
--- a/src/dmd/hdrgen.d
+++ b/src/dmd/hdrgen.d
@@ -814,8 +814,9 @@ public:
          else
          {
          L1:
+            buf.writestring("__dlang::__darray<");
              visitWithMask(t.next, t.mod);
-            buf.writestring("[]");
+            buf.writestring(">");
          }
      }
// --------------------------------

Now, equipped with that one and fairly small Natvis file that can 
be integrated into DMD somewhere and/or Code D, I've got nice 
views with flawlessly working Visual C++ Debugger on my D code. 
For matter of showcase, links with the screenshots:

1) 
https://cdn.discordapp.com/attachments/463259852311887874/491953617545330689/unknown.png
2) 
https://cdn.discordapp.com/attachments/463259852311887874/491956446469029888/unknown.png

This one can be further expanded with correct expanding of 
string, wstring, dstring and/or any other built-in 
interesting/specific/complex types from D. What people working on 
DMD think about adding something likes this? Will it break 
everything? What if that will be added as DMD command line option 
to make life easier for end user on Windows for their own 
projects (at least they may enable that temporary while 
debugging, so it won't add side effects to anything else)?

P.S. Even without any optional switch that haven't broke Mago on 
Visual D, so working with D, especially debugging, can become 
far, far easier than it's now. Even with this small change I'm 
able to continue working on my project without thinking twice why 
I haven't stayed on C++.


More information about the Digitalmars-d mailing list