Debugging Visual D using Visual D

Tue Aug 15 13:06:39 PDT 2017

On 15.08.2017 19:31, Johnson wrote:
> On Tuesday, 15 August 2017 at 07:01:34 UTC, Rainer Schuetze wrote:
>>
>>
>> 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.
>>
> 
> 
> Ok, so, what I realized was that I was still using the release version 
> of visual D to try to attach to the debugged version. I guess I should 
> use the release version to attach to the debug version and the exp debug 
> version to attach to the another exp debug version, or just install the 
> debug version as default(I was trying to avoid that since I use it for 
> other projects right now).
> 
> I set it up and added C:\Program Files (x86)\VisualD to the symbols 
> search list but no luck. Seems VS is simply not loading the pdb. (I've 
> got it listed in several locations but it never shows up under modules)
> 
> 
>>>
>>>
>>> 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.
>>
> 
> Well, I tried a bunch of stuff and nothing seems to work. In the modules 
> list, VisualD.pdb is not even listed(vdextensions is but for some path 
> like C:\s\l\... which doesn't exist on my pc).
> 
> `dumpbin /headers`
> 
> Dump of file visualD.pdb
> visualD.pdb : warning LNK4048: Invalid format file; ignored
> 
> 
> I've tried launching the experimental VS which uses the debug version to 
> debug another experimental instance but it too has the same problem. 
> procmon shows that visualD.pdb isn't even searched for(at least it's now 
> showing up).
> 
> This is all with debug coff as there is no pdb in for the standard debug.
> 
> Here's a link to the pdb.
> 
> https://ufile.io/eprlv
> 
> Maybe you can run dumpbin /headers on yours and see if errors out or 
> not. If not, then it is something in the generation of it on my side(is 
> it using cv2pdb(207,872 bytes?)).
> 
> Thanks.

dumpbin cannot display PDB files. You can use cvdump.exe from 
https://github.com/Microsoft/microsoft-pdb/tree/master/cvdump to do 
this. Your pdb file looks alright.

If you compile "Debug COFF32" conversion with cv2pdb should not be done, 
I guess it won't even be able to find any debug info.

The "Debug" configuration should create the PDB file with cv2pdb, but 
this might depend on the selected debug engine. mago understands the old 
CodeView information, so conversion is done only done for the VS debug 
engine (if "run cv2pdb" is configured to "if recommended for selected 
debug engine").

Whether you use the release or debug version of Visual D for the 
debugger devenv instance should not make a difference. You even don't 
need Visual D at all to use the debugger. IIRC only the expressions for 
the "Auto" window are supplied by Visual D.

Please double-check the module window. Is visuald.dll actually loaded 
from the path that you expect? Can you use explicit "Load Symbols" on it?

If I remember correctly, you only have VS2017 installed. I have some 
older versions of VS installed, too. Maybe there is still some component 
needed from older installations. I'll try to verify that...