Debugging Visual D using Visual D

[Rainer Schuetze via Digitalmars-d-debugger]

On 14.08.2017 16:39, Johnson Jones wrote:
> On Monday, 14 August 2017 at 06:36:22 UTC, Rainer Schuetze wrote:
>>
>>
>> On 13.08.2017 23:28, Johnson Jones wrote:
>>> One can prevent building the other projects using the configuration 
>>> manager. Seems to work fine.
>>>
>>> One problem is that I cannot seem to get breakpoints to work. Same 
>>> issues as I mentioned before with visual D saying the symbols haven't 
>>> been loaded for the document. I do not know if it's the cross 
>>> debugging issue or Visual D's issue though.
>>>
>>>
>>
>> What configuration are you using? I recently switched to "Debug 
>> COFF32" as it produced the slightly better experience and doesn't need 
>> the cv2pdb build step. "Debug" should be fine, too, though.
> 
> 
> Didn't help. To try it out, simply follow the steps I mentioned about 
> creating a separate debug install
> 
> and add the build event(modify for your version of VS)
> 
> \visuald-0.45.1-rc2\bin\Debug\quick_install.bat & "C:\Program Files 
> (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\devenv.exe" 
> SomeDSolutionToOpenForTesting.sln /RootSuffix Exp
> 
> The quick_install.bat just copies the various build files to the visual 
> D debug install directory.
> 
> e.g.,
> 
> copy /Y "\visuald-0.45.1-rc2\bin\Debug COFF32\VisualD.dll" "C:\Program 
> Files (x86)\VisualD\Debug"
> 
> What this does, is after a successful build, is copy the VisualD dll to 
> the debug install version and loads up an experimental version of visual 
> studio which uses that version if you updated it's hive, which I 
> outlined above(takes about 3 mins to modify all the entries pointing to 
> the original visual D install dir).
> 
> After that, build visual D and it should update the debug install, 
> launch exp VS, open a D project and be ready for testing.
> 
> Then go to the first VS and attach process to the second, add BP's, such 
> as on the backspace switch case, and then go in to the exp VS and hit 
> backspace, it should break, but it doesn't and the BP's say there are no 
> symbols loaded.

That's how I do it for VS2013 and VS2015 aswell (without the 
complications of the private registry). I use the Visual D debug output 
directory directly, so no copying necessary.

I tried it for VS2017 too, and it worked for me, too.

> 
> 
> There is obviously a pdb file. I've copied it to the debug install dir 
> and added the debug dir as a symbols directory so there is no reason why 
> visual studio can't find it. I've also tried different debuggers(mago, 
> visual studio, etc).
> 
> Given that this looks eerily similar to the BP problem I've experienced 
> in the past with visual D doing normal projects(no cross debugging), it 
> makes me believe it is a bug in visual D. Remember when I said I 
> couldn't get any BP's for x64? You fixed that, then I've had instances 
> where I couldn't get any for x86 after the fix.
> 

Please note that even with the (private) registry patched, it still 
loads Visual D twice, once from the debug directory, and once from the 
installation folder (see the module list). I suspect this happens 
because the global extension folder in 
%VSInstallDir%\Common7\IDE\Extensions is still scanned.

Breakpoints in viewfilter.d still point to the debug DLL and work for 
me, though.