www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Upvote!!

http://www.reddit.com/r/programming/comments/2afm4x/dconf_2014_day_2_talk_6_debugging_in_d_by_iain/

https://www.facebook.com/dlang.org/posts/882826745064341

https://twitter.com/D_Programming/status/487623887187083264


Andrei
Jul 11 2014
next sibling parent simendsjo <simendsjo gmail.com> writes:
On 07/11/2014 05:48 PM, Andrei Alexandrescu wrote:

 Upvote!!
 
 http://www.reddit.com/r/programming/comments/2afm4x/dconf_2014_day_2_talk_6_debugging_in_d_by_iain/
 
 
 https://www.facebook.com/dlang.org/posts/882826745064341
 
 https://twitter.com/D_Programming/status/487623887187083264
 
 
 Andrei


Not on HN?
Jul 11 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 11 July 2014 at 15:48:13 UTC, Andrei Alexandrescu 
wrote:

 Upvote!!

 http://www.reddit.com/r/programming/comments/2afm4x/dconf_2014_day_2_talk_6_debugging_in_d_by_iain/

 https://www.facebook.com/dlang.org/posts/882826745064341

 https://twitter.com/D_Programming/status/487623887187083264


 Andrei


Words are not even enough to express how grateful I am to Iain 
for doing this. Most stuff works with D1 builds too and I have 
completely switched to git build of gdb at work after trying it 
for a moment - huge productivity gain!
Jul 11 2014
prev sibling next sibling parent reply Iain Buclaw via Digitalmars-d-announce writes:
On 11 July 2014 16:48, Andrei Alexandrescu via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 Upvote!!

 http://www.reddit.com/r/programming/comments/2afm4x/dconf_2014_day_2_talk_6_debugging_in_d_by_iain/

 https://www.facebook.com/dlang.org/posts/882826745064341

 https://twitter.com/D_Programming/status/487623887187083264


 Andrei



Thanks for spelling my name right this year. :)
Jul 11 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/11/2014 11:15 AM, Iain Buclaw via Digitalmars-d-announce wrote:

 Thanks for spelling my name right this year. :)


Please make an AMA post!
Jul 11 2014
prev sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 11.07.2014 20:15, Iain Buclaw via Digitalmars-d-announce wrote:

 On 11 July 2014 16:48, Andrei Alexandrescu via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

 Upvote!!

 http://www.reddit.com/r/programming/comments/2afm4x/dconf_2014_day_2_talk_6_debugging_in_d_by_iain/

 https://www.facebook.com/dlang.org/posts/882826745064341

 https://twitter.com/D_Programming/status/487623887187083264


 Andrei



 Thanks for spelling my name right this year. :)


Very impressive work, Iain.

One comment about Visual D and MinGW: Visual D uses cv2pdb to convert 
both CodeView4 and DWARF debug info to PDB, so you can debug programs 
built with the MinGW tool chain and GDC inside Visual D.

TBH I have not used it that much, Manu will probably have more 
experience with it.
Jul 15 2014
prev sibling next sibling parent "Trass3r" <un known.com> writes:
http://youtu.be/n9RNxUQ0Cyk
Jul 11 2014
prev sibling next sibling parent Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
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.

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?

On 12 July 2014 04:15, Iain Buclaw via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:


 On 11 July 2014 16:48, Andrei Alexandrescu via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

 Upvote!!


 http://www.reddit.com/r/programming/comments/2afm4x/dconf_2014_day_2_talk_6_debugging_in_d_by_iain/

 https://www.facebook.com/dlang.org/posts/882826745064341

 https://twitter.com/D_Programming/status/487623887187083264


 Andrei



 Thanks for spelling my name right this year. :)
Jul 13 2014
prev sibling next sibling parent Iain Buclaw via Digitalmars-d-announce writes:
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. ;)



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

Regards
Iain.
Jul 13 2014
prev sibling next sibling parent reply Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
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?
What would a 'D debugger' have to offer when the debug backend understands
D internally, and can even handle D expression evaluation?

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...
Jul 13 2014
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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.
Jul 14 2014
next sibling parent reply Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
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.
Jul 14 2014
parent Rainer Schuetze <r.sagitario gmx.de> writes:
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.
Jul 15 2014
prev sibling parent reply Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
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.
Jul 14 2014
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 15.07.2014 04:35, 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.


 Does that mean it's working?


Yes, it might have a few quirks left, though.


 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.


If you check the mago64 branch, it shows activity about 2 months ago.


 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.
Jul 15 2014
prev sibling next sibling parent Iain Buclaw via Digitalmars-d-announce writes:
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.

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. ;-)

Iain.
Jul 14 2014
prev sibling next sibling parent reply Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
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?
Jul 14 2014
parent reply Johannes Pfau <nospam example.com> writes:
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...
Jul 14 2014
next sibling parent "Trass3r" <un known.com> writes:
 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
Jul 14 2014
prev sibling parent reply Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
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.
Jul 14 2014
next sibling parent Johannes Pfau <nospam example.com> writes:
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.
Jul 14 2014
prev sibling parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 15/07/2014 02:59, Manu via Digitalmars-d-announce wrote:

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


Linking problems aside, if GDC on Windows produces proper DWARF debug 
info, you can debug the GDC compiled code with GDB and a graphical 
frontend such as DDT+CDT, you don't need Visual Studio.
But, like you said, the Windows/MingW port of GDC is not maintained so 
it's all just theoretical as things stand.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Jul 22 2014
prev sibling parent Iain Buclaw via Digitalmars-d-announce writes:
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.
Jul 14 2014