debugger

[Doc Andrew]

On Thursday, 25 April 2019 at 13:52:22 UTC, Martin Krejcirik 
wrote:
> On Monday, 22 April 2019 at 17:26:27 UTC, Manu wrote:
>> That's very old tech, modern D compilers (last 5 years) emit 
>> PDB directly.
>
> It is still needed to create a .pdb file. Or am I missing 
> something ?

I think dmd will only emit the .pdb if compiling 64-bit code, 
because it doesn't use OPTLINK in that case. Is that what you 
mean? Just compile with the -m64, -debug and -g flags and the 
.pdb will be created in the same folder along with the rest of 
the output files.

Another very good, often overlooked option for debugging on 
Windows is WinDbg - the MS one, not the weird (maybe just very 
outdated?) one that ships with dmd.

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools

There's a little bit of a learning curve, but it's more powerful 
than the Visual Studio debugger, and it should be a bit lighter 
weight than a full MS Visual Studio + VisualD install.

As long as the .pdb is present, WinDbg seems to work great with 
dmd executables, but I haven't tested some of the more 
complicated options with heap management, etc. Local stack vars, 
threads, jumping to code, breakpoints, etc. all seem to work 
fine. One noticeable omission is that exceptions thrown from D 
don't seem to be trapped and analyzed the same way in the 
debugger, but that might be a misunderstanding on my part about 
how D exceptions work.

It's also worth checking out the "WinDbg Preview" version 
available in the Windows Store right now. It's supposed to be 
more user-friendly than the classic WinDbg, but all the commands, 
etc. still work the same way. I think it feels a lot more 
responsive, and remote symbol loading seems to work a lot better 
too.

Anybody interested in a WinDbg + D blog post?

-Doc