Debugging Visual D using Visual D

Tue Aug 15 10:31:16 PDT 2017

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.