www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - debugger

reply tester <tester aol.com> writes:
start putting a debugger into the distro. this one can be adapted 
for d needs

http://fdbg.x86asm.net
Apr 22 2019
next sibling parent Andre Pany <andre s-e-a-p.de> writes:
On Monday, 22 April 2019 at 07:45:50 UTC, tester wrote:

 start putting a debugger into the distro. this one can be 
 adapted for d needs

 http://fdbg.x86asm.net


GDB defines an interface called GDB MI. Also Mago supports this 
interface. Therefore you can use various debuggers in IDEs 
(Visual Studio Code, IntelliJ, DLang IDE, ...) which supports GDB 
MI.

On a first glance, it seems fdbg does not support GDB MI.

Can you contact the author and ask wheter he can add support for 
GDB MI?

Kind regards
Andre
Apr 22 2019
prev sibling parent reply Martin Krejcirik <mk-junk i-line.cz> writes:
On Monday, 22 April 2019 at 07:45:50 UTC, tester wrote:

 start putting a debugger into the distro. this one can be 
 adapted for d needs


dmd works with existing debuggers using cv2pdb utility on Windows.
Apr 22 2019
parent reply Manu <turkeyman gmail.com> writes:
On Mon, Apr 22, 2019 at 4:25 AM Martin Krejcirik via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Monday, 22 April 2019 at 07:45:50 UTC, tester wrote:

 start putting a debugger into the distro. this one can be
 adapted for d needs


 dmd works with existing debuggers using cv2pdb utility on Windows.


That's very old tech, modern D compilers (last 5 years) emit PDB directly.
Visual Studio + VisualD (uses the Mago debug engine) is the best
windows debugging environment by miles, there's really no competition
at the moment.
Not to mention the comprehensive autocomplete and code navigation
support, I think it's the best D has to offer despite being
systematically overlooked. DCD is quite good, but it just feels like
it has more gaps to me every time I use it.
Apr 22 2019
parent reply Martin Krejcirik <mk-junk i-line.cz> writes:
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 ?
Apr 25 2019
next sibling parent Manu <turkeyman gmail.com> writes:
On Thu, Apr 25, 2019 at 6:55 AM Martin Krejcirik via Digitalmars-d
<digitalmars-d puremagic.com> 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'm not sure what you mean?
Windows debuggers tend to use PDB files. DMD and LDC populate the
object with CV data normally, and the linker emits the PDB as usual.
Apr 25 2019
prev sibling parent reply Doc Andrew <x x.com> writes:
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
Apr 25 2019
parent reply Manu <turkeyman gmail.com> writes:
On Thu, Apr 25, 2019 at 6:51 PM Doc Andrew via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 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.


DMD has 32bit and 64bit COFF output (`-m32coff` and `-m64`), but
neither is default. For some reason it still defaults to output 32bit
OMF output fit for the 1960's, despite my best efforts to convince to
change the default to something sensible for years.


 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


Yeah the windows kernel debugger is a good debugger... but seriously,
just use VS + VisualD, there's no better experience for D that comes
even remotely close.
Apr 26 2019
parent Seb <seb wilzba.ch> writes:
On Saturday, 27 April 2019 at 04:19:16 UTC, Manu wrote:

 On Thu, Apr 25, 2019 at 6:51 PM Doc Andrew via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:

 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.


 DMD has 32bit and 64bit COFF output (`-m32coff` and `-m64`), 
 but neither is default. For some reason it still defaults to 
 output 32bit OMF output fit for the 1960's, despite my best 
 efforts to convince to change the default to something sensible 
 for years.


With 2.086, dub will behave sensible and default to COFF. My plan 
is to push the same for the next release.
Apr 27 2019