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...
