Bug 13243 – Mago doesn't seem to work for Win64

Trying out 3.39-b1, changed debugger to Mago for DMD-Win64 builds, but when I launch, all breakpoints are disabled, and it I can't debug. I change back to Visual Studio debugger, my breakpoints are working again, and debugging is as normal. Anything I need to do other that switch the debugger to Mago?

Switching the debug engine should be enough. You should not use "-gc" instead of "-g" for debug information, though. Some random ideas: - Does it launch the executable at all? - Does mago work for Win32? - Might be an installation issue: Did this entry make it into the registry? HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MagoDebugger\Remote_x64: "C:\Program Files (x86)\VisualD\Mago\MagoRemote.exe" - Have you tried it on a "hello world" program? Maybe it is stumbling over some complex debug information.

I'm not using -gc. The registry entry is present. Launch my exe, or the Mago exe? It does launch my program, but all breakpoints show as 'hollow' inactive red dots. I can't test 32bit in context since DMD doesn't write 32bit COFF. I'll try a hello world...

> I can't test 32bit in context since DMD doesn't write 32bit COFF. So I guess you are using a mixture of C++ and D? That's something I haven't tried with mago and expect to not too work well. Your breakpoints are in C++ code? If your project is D only: Mago understands both CodeView as written by optlink as well as PDB files.

(In reply to Rainer Schuetze from comment #3) > > I can't test 32bit in context since DMD doesn't write 32bit COFF. > > So I guess you are using a mixture of C++ and D? Yes, all my projects are like this. > That's something I haven't tried with mago and expect to not too work well. > Your breakpoints are in C++ code? No, they're in D. Hmmm, I hadn't considered that I'd lose C++ debugging by using Mago (is a problem) .. But it's not the issue right now. > If your project is D only: Mago understands both CodeView as written by > optlink as well as PDB files. I have no D-only code. There's nowhere near enough development in the D universe for me to work without C/C++ in parallel for now. I will produce some hello-world programs when I get a minute, but I have a suspicion that will probably work... it sounds fairly like that it's the C++ code that's killing it somehow :/

I tried linking a little C++ static library into the D file. Mago worked as usual for the D part for me, and it didn't completely fail for the C++ part. Breakpoints didn't trigger there, and stepping worked as if it where on the processor instructions.

I noticed that section offsets were truncated to 16-bit. This was causing the trouble with the bad C++ breakpoints and stepping. I believe this could also have been a problem in non-trivial D programs. Please try the new beta: https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.39-beta2

Nope, no luck. I just tried a 'hello world' project, and that didn't work either. These steps: File -> New -> Project -> D -> Console Application This creates a Win32 'hello world' project. Project -> Properties -> Debugging -> Choose Mago Place breakpoint on writeln, debug, breaks at breakpoint. Mago works as expected. Configuration Manager -> Active Solution Platform -> New... -> x64, copy from Win32 Build and run x64 build. Breakpoint goes 'hollow', doesn't break. Mago doesn't seem to work. Switch back to Visual Studio debugger, breakpoint works as expected.

Thanks for trying. I could now reproduce the problem with the VS2012 shell on a fresh installation: the COM class ID for the DIA DLL msdia*.dll (used to access the PDB file) changed between VS versions (but not before VS2010), and only the VS2013 ID was used so far. I have added trying the earlier versions, too. The beta2-installer is replaced by the new version, I didn't bother to make a new tag. Please give it another try.

(In reply to Rainer Schuetze from comment #8) > Thanks for trying. I could now reproduce the problem with the VS2012 shell > on a fresh installation: the COM class ID for the DIA DLL msdia*.dll (used > to access the PDB file) changed between VS versions (but not before VS2010), > and only the VS2013 ID was used so far. > > I have added trying the earlier versions, too. The beta2-installer is > replaced by the new version, I didn't bother to make a new tag. Please give > it another try. Okay, well, it works now... except there's a new problem. It takes 40-50 seconds to launch the exe, so every time I restart I have to wait a minute. Switch back to VS debugger, and it launches immediately as usual.

(In reply to Manu from comment #9) > > Okay, well, it works now... except there's a new problem. > It takes 40-50 seconds to launch the exe, so every time I restart I have to > wait a minute. > Switch back to VS debugger, and it launches immediately as usual. At least, some progress :) I noticed a delay of a few seconds in my tests, but these were probably just too small projects. There is some problem with mapping PDB semantics to the way mago handles symbols and line number lookup, which is very much tuned to match CodeView data as stored in the Win32 executable. I refactored it a little to better take advantage of the way you have to access line numbers in PDB files and updated beta2 again.

Mago now works for x64. Please test if it is still too slow for your projects, I recommend opening another issue for that. I have just released https://github.com/D-Programming-Language/visuald/releases/download/v0.3.39/VisualD-v0.3.39.exe

It is working well. The slow startup is gone. Thanks again, as always! :) The Mago debugging experience has some rough edges, evaluation of some types seems is a bit funny. I'll start logging individual bugs for each of the cases. Overall though, much better. Finally, I can debug classes now! I think with a few small fixes, we should aim for Mago to become the default.