On 14 July 2014 21:14, Iain Buclaw via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On 14 July 2014 07:22, Manu via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> > On 14 July 2014 15:58, Iain Buclaw via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> >>
> >> On 14 July 2014 06:19, Manu via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> >> > I finally watched it (I failed to survive the long over-nighters until
> >> > 10am
> >> > to watch this one live >_<).
> >> >
> >> > I want to offer congratulation and thanks to Iain for this work!
> >> > For me, this is perhaps the single most important work in the D
> >> > ecosystem
> >> > yet this year, and for me, I think the debugging environment remains
> the
> >> > single most significant hurdle to confident and practical adoption of
> D
> >> > in
> >> > industry.
> >> >
> >>
> >> Thanks Manu.  I guess I'll be having trouble finding the next most important work in the D ecosystem next year. ;)
> >
> >
> > I think you've probably earned a break ;)
> >
> >
> >> > It brings me to the interesting realisation (which I already knew, I
> >> > have
> >> > just been denying), that for D to proceed on Windows, MSVC will have
> to
> >> > go... and I don't know how to go about this :/
> >> > MS's debugger will presumably never support these features, but the de
> >> > facto
> >> > Windows toolchain emit's PDB for use with the MS tools. I wonder if
> >> > there
> >> > are competing debuggers that support PDB which could support
> unofficial
> >> > extensions to PDB which may express D better?
> >> >
> >>
> >> Zerobugs was aimed at D users back when it was a commercial product. It has since been released under a boost licensed for a couple years now, but has into gone into obscurity (I think?).
> >>
> >> Link: http://zerobugs.codeplex.com
> >> Couple of clones on github too: https://github.com/search?q=zerobugs
> >>
> >> Being written against GTK, it's UI should be cross-platform to Windows, so it *could* be a good base project to start from, then build Windows debugging support into it.  Someone else will need to do initial reviewing and triaging of this stuff (we need a new Lieutenant!)
> >
> >
> > On the back of your work, what advantage would that debugger have over established and more refined tools?
>
> I've never used zerobugs, but it looked interesting a few years back, but didn't think it worth the money (actually, I seldom purchase software) in comparison to FOSS.
>
>
> > What would a 'D debugger' have to offer when the debug backend
> understands D
> > internally, and can even handle D expression evaluation?
> >
>
> I think the experience is simply more natural to the end user.  You code in D, you debug in D.  I do it all the time for C++ when I'm probing for a problem in gdc.  Copying a line of code and pasting it into the command prompt, checking the result.  It's one of these features that I never noticed until I started doing this work in gdb. *Then* I realised that I would have to implement a ground-up interpreter for D.


Okay, so I'm confused. You said you're working on an expression parser for
D right? Assuming that is present, why would a D-specific debugger have any
advantage over an existing debugger with your GDC?
Or is the point that zerobugs already rolls its own debugger which has an
expression parser?

Luckily GDB has awesome support for many language concepts, both in
> functional and procedural languages.  So most of the work was just extending existing opcodes to behave in a D-like manor. ;-)
>

Right.
Do you know about LLDB? I presume it'll be equally competent?
I don't see that GDC/GDB will ever be useful in the Windows environment due
to incompatible object and debug formats, but LLVM are making the push for
full MSVC compatibility. With that, you should be able to (finally!) use
Clang(/LDC) in place of MSVC, so then we're left with the debug
environment... If LLVM are making a commitment to producing Microsoft
object and debug output, it stands to reason that LLDB will support them
too?

On 14 July 2014 15:15, Manu via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> On 14 July 2014 21:14, Iain Buclaw via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>>
>> On 14 July 2014 07:22, Manu via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>> > On 14 July 2014 15:58, Iain Buclaw via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>> >>
>> >> On 14 July 2014 06:19, Manu via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>> >> > I finally watched it (I failed to survive the long over-nighters
>> >> > until
>> >> > 10am
>> >> > to watch this one live >_<).
>> >> >
>> >> > I want to offer congratulation and thanks to Iain for this work!
>> >> > For me, this is perhaps the single most important work in the D
>> >> > ecosystem
>> >> > yet this year, and for me, I think the debugging environment remains
>> >> > the
>> >> > single most significant hurdle to confident and practical adoption of
>> >> > D
>> >> > in
>> >> > industry.
>> >> >
>> >>
>> >> Thanks Manu.  I guess I'll be having trouble finding the next most important work in the D ecosystem next year. ;)
>> >
>> >
>> > I think you've probably earned a break ;)
>> >
>> >
>> >> > It brings me to the interesting realisation (which I already knew, I
>> >> > have
>> >> > just been denying), that for D to proceed on Windows, MSVC will have
>> >> > to
>> >> > go... and I don't know how to go about this :/
>> >> > MS's debugger will presumably never support these features, but the
>> >> > de
>> >> > facto
>> >> > Windows toolchain emit's PDB for use with the MS tools. I wonder if
>> >> > there
>> >> > are competing debuggers that support PDB which could support
>> >> > unofficial
>> >> > extensions to PDB which may express D better?
>> >> >
>> >>
>> >> Zerobugs was aimed at D users back when it was a commercial product. It has since been released under a boost licensed for a couple years now, but has into gone into obscurity (I think?).
>> >>
>> >> Link: http://zerobugs.codeplex.com
>> >> Couple of clones on github too: https://github.com/search?q=zerobugs
>> >>
>> >> Being written against GTK, it's UI should be cross-platform to Windows, so it *could* be a good base project to start from, then build Windows debugging support into it.  Someone else will need to do initial reviewing and triaging of this stuff (we need a new Lieutenant!)
>> >
>> >
>> > On the back of your work, what advantage would that debugger have over established and more refined tools?
>>
>> I've never used zerobugs, but it looked interesting a few years back, but didn't think it worth the money (actually, I seldom purchase software) in comparison to FOSS.
>>
>>
>> > What would a 'D debugger' have to offer when the debug backend
>> > understands D
>> > internally, and can even handle D expression evaluation?
>> >
>>
>> I think the experience is simply more natural to the end user.  You code in D, you debug in D.  I do it all the time for C++ when I'm probing for a problem in gdc.  Copying a line of code and pasting it into the command prompt, checking the result.  It's one of these features that I never noticed until I started doing this work in gdb. *Then* I realised that I would have to implement a ground-up interpreter for D.
>
>
> Okay, so I'm confused. You said you're working on an expression parser for D
> right? Assuming that is present, why would a D-specific debugger have any
> advantage over an existing debugger with your GDC?
> Or is the point that zerobugs already rolls its own debugger which has an
> expression parser?
>
>> Luckily GDB has awesome support for many language concepts, both in functional and procedural languages.  So most of the work was just extending existing opcodes to behave in a D-like manor. ;-)
>

Zerobugs rolls its own debugger, its only strength vs GDB is that being separate from the GNU toolchain, it may be more friendly to getting in PDB/MSVC support, for instance.


> Right.
> Do you know about LLDB? I presume it'll be equally competent?
> I don't see that GDC/GDB will ever be useful in the Windows environment due
> to incompatible object and debug formats, but LLVM are making the push for
> full MSVC compatibility. With that, you should be able to (finally!) use
> Clang(/LDC) in place of MSVC, so then we're left with the debug
> environment... If LLVM are making a commitment to producing Microsoft object
> and debug output, it stands to reason that LLDB will support them too?

I haven't looked at LLDB I'm afraid, so I can't comment.

Am Tue, 15 Jul 2014 00:15:01 +1000
schrieb Manu via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com>:

> I don't see that GDC/GDB will ever be useful in the Windows environment due to incompatible object and debug formats, but LLVM are making the push for full MSVC compatibility.

Can you provide some more details about this? MinGW uses the standard PE object format, afaik. GCC-4.9 also supports SEH exceptions (on 64 bit, not sure about 32). The mingw 'runtime' is a small layer on top of the microsoft runtime, to provide C99 functions and similar stuff. I don't think that should be a problem.

The pdb debug format is not supported, AFAIK. But that format is not
documented and I don't think you could add D extensions anyway.
So does LLVM really support PDB?

MinGW can use dwarf debug info on windows and I guess you get all benefits of Iain's gdb work on windows. It is annoying if you get crashes in the microsoft C runtime or any other library compiled with microsoft tools though, as there's no dwarf debug info for these.

So overall I don't see why mingw should work fine on windows. Of course there's less incentive for GCC devs to support windows, but I doubt that's different for LLVM.

There's also nobody working actively on the MinGW gdc port right now, afaik. We don't even know the test suite results for mingw. So if you want to contribute...

On 14.07.2014 08:22, Manu via Digitalmars-d-announce wrote:
> There are alternative tools available for windows too, but I think the
> key for Windows developers remains proper integration into Visual
> Studio, and PDB support.
> I guess the biggest hurdle there is integrating D concepts info into
> MS's proprietary PDB format. Expressing debug info like C really won't
> get us the full mile.
> Rainer bundles Mago with VisualD. I wonder what that's doing lately...

Aldo has put a lot of work in extending mago to 64-bit. I guess the next version of Visual D will come with it.

Mago had D expression evaluation from the start, showing associative array elements was added a bit later.

> The pdb debug format is not supported, AFAIK. But that format is not documented and I don't think you could add D extensions anyway.
> So does LLVM really support PDB?

As long as they rely on the MS linker they only need to emit proper debug info into the object files. But that's still TODO: http://clang.llvm.org/docs/MSVCCompatibility.html#abi-features

On 15 July 2014 00:32, Johannes Pfau via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> Am Tue, 15 Jul 2014 00:15:01 +1000
> schrieb Manu via Digitalmars-d-announce
> <digitalmars-d-announce@puremagic.com>:
>
> > I don't see that GDC/GDB will ever be useful in the Windows environment due to incompatible object and debug formats, but LLVM are making the push for full MSVC compatibility.
>
> Can you provide some more details about this? MinGW uses the standard PE object format, afaik. GCC-4.9 also supports SEH exceptions (on 64 bit, not sure about 32). The mingw 'runtime' is a small layer on top of the microsoft runtime, to provide C99 functions and similar stuff. I don't think that should be a problem.
>

http://clang.llvm.org/docs/MSVCCompatibility.html

They emit line numbers so far apparently. But I understand the intent is to
properly populate the object with cv8 debug data.
The linker takes care of generating the pdb file.

So, are you saying that GDC binaries will link successfully against the
mscrt suite?
I've used it in the past, and it never wanted to link against the ms libs.
In addition, when I did try and link C and D code together, I got loads of
CRT conflicts when trying to link glibc and mscrt together.

I believe the goal for LLVM is to target the same runtime as MSC does, otherwise you're just asking for link trouble.

The pdb debug format is not supported, AFAIK. But that format is not
> documented and I don't think you could add D extensions anyway. So does LLVM really support PDB?
>

The linker outputs the pdb file, the objects are populated with cv8. Can GCC write cv8 output?

I'm sure it's possible to creatively coax the cv8 data blocks to store
non-MS data without being stripped or crashing the linker...
That said, I don't know anything about cv8/pdb, and if it's able to
sufficiently express D concepts as is. MS supports quite a few languages,
so it must be reasonably competent as it is...?

MinGW can use dwarf debug info on windows and I guess you get all
> benefits of Iain's gdb work on windows. It is annoying if you get crashes in the microsoft C runtime or any other library compiled with microsoft tools though, as there's no dwarf debug info for these.
>

I have had problems with the linker when trying to link GDC and MSC objects
together.
You lose the debug info for one or the other world. You can't have dwarf
and cv8/pdb together.
And to be useful, there would need to be some visual studio integration for
dwarf debugging :/

So overall I don't see why mingw should work fine on windows. Of
> course there's less incentive for GCC devs to support windows, but I doubt that's different for LLVM.
>

I think there would be plenty of incentive if it worked.
I haven't tried it out for a while. I'll give it a whirl and see what's
changed, but while the dwarf/cv8 conflict remains, I can't see it being a
practical solution.

There's also nobody working actively on the MinGW gdc port right now,
> afaik. We don't even know the test suite results for mingw. So if you want to contribute...
>

This has indeed been my biggest issue with GDC in the past.

On 15 July 2014 04:27, Rainer Schuetze via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

>
>
> On 14.07.2014 08:22, Manu via Digitalmars-d-announce wrote:
>
>> There are alternative tools available for windows too, but I think the
>> key for Windows developers remains proper integration into Visual
>> Studio, and PDB support.
>> I guess the biggest hurdle there is integrating D concepts info into
>> MS's proprietary PDB format. Expressing debug info like C really won't
>> get us the full mile.
>> Rainer bundles Mago with VisualD. I wonder what that's doing lately...
>>
>
> Aldo has put a lot of work in extending mago to 64-bit. I guess the next version of Visual D will come with it.
>
> Mago had D expression evaluation from the start, showing associative array elements was added a bit later.
>

Have you tried it out? How does it deal with some of the cases Iain brought up; enum's, globals/statics, tls, etc.

On 15 July 2014 04:27, Rainer Schuetze via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

>
>
> On 14.07.2014 08:22, Manu via Digitalmars-d-announce wrote:
>
>> There are alternative tools available for windows too, but I think the
>> key for Windows developers remains proper integration into Visual
>> Studio, and PDB support.
>> I guess the biggest hurdle there is integrating D concepts info into
>> MS's proprietary PDB format. Expressing debug info like C really won't
>> get us the full mile.
>> Rainer bundles Mago with VisualD. I wonder what that's doing lately...
>>
>
> Aldo has put a lot of work in extending mago to 64-bit. I guess the next version of Visual D will come with it.
>

Does that mean it's working?
It's very hard to tell from the project website. TBH, I actually thought
Mago was a dead project for years because the last activity on the website
looks like 2012.
He should consider moving to github, then we can have some visibility.

Mago had D expression evaluation from the start, showing associative array
> elements was added a bit later.
>

Am Tue, 15 Jul 2014 11:59:42 +1000
schrieb Manu via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com>:

> On 15 July 2014 00:32, Johannes Pfau via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:
> 
> > Am Tue, 15 Jul 2014 00:15:01 +1000
> > schrieb Manu via Digitalmars-d-announce
> > <digitalmars-d-announce@puremagic.com>:
> >
> > > I don't see that GDC/GDB will ever be useful in the Windows environment due to incompatible object and debug formats, but LLVM are making the push for full MSVC compatibility.
> >
> > Can you provide some more details about this? MinGW uses the standard PE object format, afaik. GCC-4.9 also supports SEH exceptions (on 64 bit, not sure about 32). The mingw 'runtime' is a small layer on top of the microsoft runtime, to provide C99 functions and similar stuff. I don't think that should be a problem.
> >
> 
> http://clang.llvm.org/docs/MSVCCompatibility.html
> 
> They emit line numbers so far apparently. But I understand the intent
> is to properly populate the object with cv8 debug data.
> The linker takes care of generating the pdb file.
> 
> So, are you saying that GDC binaries will link successfully against
> the mscrt suite?
> I've used it in the past, and it never wanted to link against the ms
> libs. In addition, when I did try and link C and D code together, I
> got loads of CRT conflicts when trying to link glibc and mscrt
> together.

There's no glibc on windows, mingw links to msvcrt.dll. I think MS
toolchains link to msvcr110.dll, but it's also possible to make mingw
link against msvcr110.dll.
I didn't try to link mingw/msvc object files yet, but according to some
mingw discussions it should work. C DLLs should always work.

(That's only for C, C++ mingw/msvc are not compatible).

> 
> I believe the goal for LLVM is to target the same runtime as MSC does, otherwise you're just asking for link trouble.
> 
> The pdb debug format is not supported, AFAIK. But that format is not
> > documented and I don't think you could add D extensions anyway. So does LLVM really support PDB?
> >
> 
> The linker outputs the pdb file, the objects are populated with cv8. Can GCC write cv8 output?
> 

No it can't. cv2pdb claims to support converting from dwarf->pdb but I never tried that.

> MinGW can use dwarf debug info on windows and I guess you get all
> > benefits of Iain's gdb work on windows. It is annoying if you get crashes in the microsoft C runtime or any other library compiled with microsoft tools though, as there's no dwarf debug info for these.
> >
> 
> I have had problems with the linker when trying to link GDC and MSC
> objects together.
> You lose the debug info for one or the other world. You can't have
> dwarf and cv8/pdb together.
> And to be useful, there would need to be some visual studio
> integration for dwarf debugging :/
> 
> So overall I don't see why mingw should work fine on windows. Of
> > course there's less incentive for GCC devs to support windows, but I doubt that's different for LLVM.
> >
> 
> I think there would be plenty of incentive if it worked.
> I haven't tried it out for a while. I'll give it a whirl and see
> what's changed, but while the dwarf/cv8 conflict remains, I can't see
> it being a practical solution.

I guess getting dwarf and cv8 to work together is almost impossible.
> 
> There's also nobody working actively on the MinGW gdc port right now,
> > afaik. We don't even know the test suite results for mingw. So if you want to contribute...
> >
> 
> This has indeed been my biggest issue with GDC in the past.
> 

On 15.07.2014 04:02, Manu via Digitalmars-d-announce wrote:
> On 15 July 2014 04:27, Rainer Schuetze via Digitalmars-d-announce
> <digitalmars-d-announce@puremagic.com
> <mailto:digitalmars-d-announce@puremagic.com>> wrote:
>
>
>
>     On 14.07.2014 08:22, Manu via Digitalmars-d-announce wrote:
>
>         There are alternative tools available for windows too, but I
>         think the
>         key for Windows developers remains proper integration into Visual
>         Studio, and PDB support.
>         I guess the biggest hurdle there is integrating D concepts info into
>         MS's proprietary PDB format. Expressing debug info like C really
>         won't
>         get us the full mile.
>         Rainer bundles Mago with VisualD. I wonder what that's doing
>         lately...
>
>
>     Aldo has put a lot of work in extending mago to 64-bit. I guess the
>     next version of Visual D will come with it.
>
>     Mago had D expression evaluation from the start, showing associative
>     array elements was added a bit later.
>
>
> Have you tried it out? How does it deal with some of the cases Iain
> brought up; enum's, globals/statics, tls, etc.

It works, but not to the extend as described by Iain. Some of the issues need compiler support, like name symbol lookup through imports. IIRC unqualified globals/statics only work within the scope of their declaration (e.g. function statics), TLS should be ok.