DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw

[Iain Buclaw via Digitalmars-d-announce]

On 14 July 2014 15:15, Manu via Digitalmars-d-announce
<digitalmars-d-announce at puremagic.com> wrote:
> On 14 July 2014 21:14, Iain Buclaw via Digitalmars-d-announce
> <digitalmars-d-announce at puremagic.com> wrote:
>>
>> On 14 July 2014 07:22, Manu via Digitalmars-d-announce
>> <digitalmars-d-announce at puremagic.com> wrote:
>> > On 14 July 2014 15:58, Iain Buclaw via Digitalmars-d-announce
>> > <digitalmars-d-announce at puremagic.com> wrote:
>> >>
>> >> On 14 July 2014 06:19, Manu via Digitalmars-d-announce
>> >> <digitalmars-d-announce at 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.