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

http://fdbg.x86asm.net

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

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.

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.

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 ?

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.

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

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.

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.