Bug 11902 – DMD debuginfo doesn't seem to write classes correctly

DMD-Win64: While debugging in Visual Studio, inspecting classes doesn't seem to work properly. Hovering over a class instance: It shows the class pointer correctly. Clicking '+' to reveal the members shows a list with the correct number of members... But each member shows "?" as the member name, and doesn't show any value to the right, and a little red "No Entry" symbol if you hover over it. Pasting into the watch window just shows a blank line for each member. Bonus: The implicit typeinfo and vtable pointers should be present in the class too Tested with VS2010.

The problem is that the VS debugger is confused by '.' in type names. That is why cv2pdb translates these to '@'. So far, Walter rejected the proposal to also do this translation in the Win64 debug output.

Well I think he needs to come up with something if not that, because it can't go on not being able to inspect classes. Do you know any workarounds?

(In reply to comment #1) > The problem is that the VS debugger is confused by '.' in type names. That is > why cv2pdb translates these to '@'. Sorry if this is a dumb question, but would : or :: (as for C++) work instead? @ is an unusual character to delimit namespace path components...

(In reply to comment #2) > Well I think he needs to come up with something if not that, because it can't > go on not being able to inspect classes. > Do you know any workarounds? One point in Walter's favor is that VS2012 contains two debug engines, one that works with '.', but fails to display other things locals in watches. The other is the "old" engine that needs the patch (enabled by "native edit and continue"). So it seems like the bug is in the VS engine, not dmd, but that doesn't help in making it work. I don't know other workarounds. IIRC ':' doesn't work. cv2pdb has option -s to configure the '.' replacement character, so you can try some alternatives using a win32 build.

(In reply to comment #4) > One point in Walter's favor is that VS2012 contains two debug engines, one that > works with '.', but fails to display other things locals in watches. The other > is the "old" engine that needs the patch (enabled by "native edit and > continue"). So it seems like the bug is in the VS engine, not dmd, but that > doesn't help in making it work. Well, considering that we have no control over VS, and it needs to work, I suggest the patch be available under a compiler flag? Then VisualD can pass the appropriate flag implicitly depending which version of Visual Studio it detects the user is running. We need to make the windows debugging environment seamless, and I think Walter still agrees on that.

Walter: can you please chime in on this one? It's a massive hole in the windows debugging experience, and it would be super-awesome if a fix can get in on DMD 2.065... I have a lot of classes, and 'this' is almost always a class, so I'm getting very little value out of the debugger at the moment.

I do agree that we're forced to live with any bugs in VS. Even if Microsoft fixes them, those fixes often don't wind up on users' machines. If @ is the only thing that will work across the VS versions, I'll pull Rainer's patch for it. I just think it's painfully ugly.

(In reply to comment #7) > I do agree that we're forced to live with any bugs in VS. Even if Microsoft > fixes them, those fixes often don't wind up on users' machines. > > If @ is the only thing that will work across the VS versions, I'll pull > Rainer's patch for it. I just think it's painfully ugly. Does it make sense to activate it on a compile flag, then VD can supply it when it needs to? If there are differences between the 2 debug engines, then it makes sense to support the newer debug engine one by default, and the old one on a compile flag, especially since VS2008-2010 are still in very common use. I'm sure Rainer knows the most appropriate way to handle these problems.

I think it would be good to actuvate the @ mangling with a compiler flag. 64-bit support is currenlty beeing built into Mago (http://dsource.org/projects/mago_debugger). As soon as this is done and its fully working, I would think that mago will be the primary choice to debug D on Windows within Visual Studio, as it supports D specific debugging features (e.g. evaluating D expressions). And as soon as mago becomes the defacto standard for debugging the @ mangling is no longer needed. So adding a switch as temporary solution might be the best choice.

Is a solution for this going to make it into 2.065? This is the biggest problem with debugging DMD code at the moment.

https://github.com/D-Programming-Language/dmd/pull/3189 I honestly don't think that my two pull requests will make it in time for 2.065, especially as 2.065 is already in the release canidate phase.

(In reply to comment #11) > https://github.com/D-Programming-Language/dmd/pull/3189 > > I honestly don't think that my two pull requests will make it in time for > 2.065, especially as 2.065 is already in the release canidate phase. Yeah. That's a shame. I think this is pretty critical.

(In reply to Manu from comment #12) > (In reply to comment #11) > > https://github.com/D-Programming-Language/dmd/pull/3189 > > > > I honestly don't think that my two pull requests will make it in time for > > 2.065, especially as 2.065 is already in the release canidate phase. > > Yeah. That's a shame. I think this is pretty critical. 3189 was merged on Apr 7.

Thanks walter! Rainer: Is it possible to make VisualD manage this build flag appropriately according to the version of VisualStudio (or perhaps, which debug engine) the user is running?

The "debug info" selector has "Symbolic (suitable for Mago)" and "Symbolic (suitable for VS debug engine)". It could be derived from the selected debug engine, it already does that when determining whether to run cv2pdb or not. Unfortunately, this falls short when building libraries as the actually used debug engine isn't known then. I was thinking of another option "suitable for selected debug engine" to cover the most common cases.