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