www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Debugging support for D - wiki

reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
I'm looking to begin adding integrated debugger support for the DDT IDE 
pretty soon. With this in mind it would be desirable to have a view of 
what level of D language debugger support is there for the various 
combinations of platform+compiler+debugger.

This information would be quite beneficial to regular D users as well, 
as Manu's recent thread on the importance of a debugger is any 
indication of. Yet there doesn't seem to be any info about this in the 
wiki. The debuggers wiki page ( http://wiki.dlang.org/Debuggers ) 
doesn't even list the main players in this scene (VisualD/Mago, GDB, 
WinDebugger?)


I might get started with this, but I would need to enlist the help of 
other people for the other platforms/debuggers I don't have proper acess to.

The only combinations I tried so far was DMD+Windows+GDB, which seems 
like it's not supported at all. And GDC+Windows32+GDB which does seem to 
be well supported (GDB understands D name mangling, breakpoints in 
source, D data structures layout, etc.). I'm guessing GDC+GDB on Linux 
works just as well. (what about Mac though?)

Several questions remain:
Is debugger support with DMD+Linux+GDB as good as it is with GDC?
For DMD+Windows, is there only good debugger support with VisualD? :-(
And how well does that work with 32/64 bit platform variations?

It would be great to have these answered, and going forward, keeping 
track of this info in the wiki.

-- 
Bruno Medeiros - Software Engineer
Sep 23 2013
next sibling parent "Michael" <pr m1xa.com> writes:
What about Win64 and VS Debugger?
Sep 23 2013
prev sibling next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 23 September 2013 20:50, Bruno Medeiros
<brunodomedeiros+dng gmail.com> wrote:
 I'm looking to begin adding integrated debugger support for the DDT IDE
 pretty soon. With this in mind it would be desirable to have a view of what
 level of D language debugger support is there for the various combinations
 of platform+compiler+debugger.

 This information would be quite beneficial to regular D users as well, as
 Manu's recent thread on the importance of a debugger is any indication of.
 Yet there doesn't seem to be any info about this in the wiki. The debuggers
 wiki page ( http://wiki.dlang.org/Debuggers ) doesn't even list the main
 players in this scene (VisualD/Mago, GDB, WinDebugger?)


 I might get started with this, but I would need to enlist the help of other
 people for the other platforms/debuggers I don't have proper acess to.

 The only combinations I tried so far was DMD+Windows+GDB, which seems like
 it's not supported at all. And GDC+Windows32+GDB which does seem to be well
 supported (GDB understands D name mangling, breakpoints in source, D data
 structures layout, etc.). I'm guessing GDC+GDB on Linux works just as well.
 (what about Mac though?)

GDB doesn't understand D mangling. We currently leverage the use of setting pretty-print names for debugging purposes, but you require to put the names in 'quotation.marks' - I will fix this sometime this year... maybe. :) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 23 2013
parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 23/09/2013 23:57, Iain Buclaw wrote:
 On 23 September 2013 20:50, Bruno Medeiros
 <brunodomedeiros+dng gmail.com> wrote:
 I'm looking to begin adding integrated debugger support for the DDT IDE
 pretty soon. With this in mind it would be desirable to have a view of what
 level of D language debugger support is there for the various combinations
 of platform+compiler+debugger.

 This information would be quite beneficial to regular D users as well, as
 Manu's recent thread on the importance of a debugger is any indication of.
 Yet there doesn't seem to be any info about this in the wiki. The debuggers
 wiki page ( http://wiki.dlang.org/Debuggers ) doesn't even list the main
 players in this scene (VisualD/Mago, GDB, WinDebugger?)


 I might get started with this, but I would need to enlist the help of other
 people for the other platforms/debuggers I don't have proper acess to.

 The only combinations I tried so far was DMD+Windows+GDB, which seems like
 it's not supported at all. And GDC+Windows32+GDB which does seem to be well
 supported (GDB understands D name mangling, breakpoints in source, D data
 structures layout, etc.). I'm guessing GDC+GDB on Linux works just as well.
 (what about Mac though?)

GDB doesn't understand D mangling. We currently leverage the use of setting pretty-print names for debugging purposes, but you require to put the names in 'quotation.marks' - I will fix this sometime this year... maybe. :)

Perhaps I described it incorrectly then. What I mean is that most references and displays of D symbols are made using proper D names, and not mangled names (as you might get if you run it through a pure C/C++ debugger). I've haven't yet seen something like "_D8func_mod5funczFZv" on GDB compiled with GDC. BTW, when do you need to use quotation marks (other than printing global variables)? I didnt need to use quotation marks to set function breakpoints. (I'm a GDB newbie so I'm still exploring the functionality it has.) -- Bruno Medeiros - Software Engineer
Sep 25 2013
parent Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 25/09/2013 14:45, Bruno Medeiros wrote:
 Perhaps I described it incorrectly then. What I mean is that most
 references and displays of D symbols are made using proper D names, and
 not mangled names (as you might get if you run it through a pure C/C++
 debugger). I've haven't yet seen something like "_D8func_mod5funczFZv"
 on GDB compiled with GDC.

Ok, I've just seen some mangled names when using templated classes, the template instance shows up with a partially mangled name... -- Bruno Medeiros - Software Engineer
Sep 25 2013
prev sibling next sibling parent reply "eles" <eles eles.com> writes:
On Monday, 23 September 2013 at 19:50:35 UTC, Bruno Medeiros 
wrote:
 Is debugger support with DMD+Linux+GDB as good as it is with 
 GDC?

I could test with GDC and DMD on Linux (for GDB). OTOG, simple quetsion: how to install/update DDT plugin to the git HEAD version?
Sep 23 2013
parent Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 24/09/2013 14:42, eles wrote:
 On Monday, 23 September 2013 at 23:45:12 UTC, eles wrote:
 On Monday, 23 September 2013 at 19:50:35 UTC, Bruno Medeiros wrote:
 OTOG, simple quetsion: how to install/update DDT plugin to the git
 HEAD version?

Found that. Could you, please, tag the different releaseed versions, it is helpful when testing for regressions.

Ok, I've tagged 0.8.1 and will start tagging future releases. -- Bruno Medeiros - Software Engineer
Sep 25 2013
prev sibling next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 23.09.2013 21:50, Bruno Medeiros wrote:
 For DMD+Windows, is there only good debugger support with VisualD? :-(
 And how well does that work with 32/64 bit platform variations?

Current options that I know of for Windows: - DMD/Win32+windbg(1996): This is a version of windbg from 1996 with very basic debugging support and is an embarrassment to be delivered with dmd. - DMD/Win32+cv2pdb: cv2pdb allows conversion of the (often no longer supported) CodeView 4 debug info into pdb files and makes debugging available by most C/C++ debuggers. This is also used by Visual D when using the VS debugger. You can see a list features that work or don't work here: http://dsource.org/projects/cv2pdb/wiki/Features For non-VS debuggers, most of the visualization extras for displaying strings, dynamic and associative arrays will not be available. - DMD/Win32+mago: mago is a debug engine for Visual Studio explicitely for D. Most notably, it has watch support for D expressions whereas in other debuggers you usually have to know the C-representation. It can be used with/without Visual D, but things like the "Auto" window only work with language support by Visual D. - DMD/Win64: dmd emits MS compatible debug information so that the appropriate PDB file is generated during linking and debugging is possible with most C/C++ debuggers. Debug info is not yet optimal, mostly because the VS debugger does not like '.' in names. (cv2pdb defaults to replacing it with ' '). - DMD/Win32+ddbg: ddbg is linked from the web site to http://ddbg.mainia.de/releases.html but this seems a dead link. Last time I tried ddbg some years ago it didn't work out too well for me (maybe it's mostly for D1). - GDC+cv2pdb: cv2pdb is also able to convert DWARF debug information to PDB files. As DWARF is more complex than (documented) CodeView debug information, expect some more quirks than with
Sep 23 2013
parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 24/09/2013 07:16, Rainer Schuetze wrote:
 On 23.09.2013 21:50, Bruno Medeiros wrote:
 For DMD+Windows, is there only good debugger support with VisualD? :-(
 And how well does that work with 32/64 bit platform variations?

Current options that I know of for Windows: - DMD/Win32+windbg(1996): This is a version of windbg from 1996 with very basic debugging support and is an embarrassment to be delivered with dmd. - DMD/Win32+cv2pdb: cv2pdb allows conversion of the (often no longer supported) CodeView 4 debug info into pdb files and makes debugging available by most C/C++ debuggers. This is also used by Visual D when using the VS debugger. You can see a list features that work or don't work here: http://dsource.org/projects/cv2pdb/wiki/Features For non-VS debuggers, most of the visualization extras for displaying strings, dynamic and associative arrays will not be available. - DMD/Win32+mago: mago is a debug engine for Visual Studio explicitely for D. Most notably, it has watch support for D expressions whereas in other debuggers you usually have to know the C-representation. It can be used with/without Visual D, but things like the "Auto" window only work with language support by Visual D. - DMD/Win64: dmd emits MS compatible debug information so that the appropriate PDB file is generated during linking and debugging is possible with most C/C++ debuggers. Debug info is not yet optimal, mostly because the VS debugger does not like '.' in names. (cv2pdb defaults to replacing it with ' '). - DMD/Win32+ddbg: ddbg is linked from the web site to http://ddbg.mainia.de/releases.html but this seems a dead link. Last time I tried ddbg some years ago it didn't work out too well for me (maybe it's mostly for D1).

Thanks for the info, that is quite helpful. Though, it does mean that the path for good debugging support in Windows for DMD generated executables, without being tied to an specific IDE (VisualD), doesn't look good. ddbg looks quite dead. I haven't tried it myself recently but I think I recall seing some comments for other people as well that it wasn't working properly anymore with newer D versions, or something. It might be feasable to adapt mago to be used from another IDE. Can a command-line interface for it be written? Or is mago too closely tied to VisualStudio? How about having DMD generate DWARF info on Windows? Is that feasable? Is it a lot of work? If DMD does it for Linux, it doesn't seem like it should be a lot of work to have that done in Windows as well. I guess it would it would have to use GNU tooling on Windows (Cygwin or MSys), but that seems quite an acceptable requirement. (might that adress some Optlink bugs/limitations as well?) -- Bruno Medeiros - Software Engineer
Sep 25 2013
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 25.09.2013 17:12, Bruno Medeiros wrote:
 On 24/09/2013 07:16, Rainer Schuetze wrote:
 On 23.09.2013 21:50, Bruno Medeiros wrote:
 For DMD+Windows, is there only good debugger support with VisualD? :-(
 And how well does that work with 32/64 bit platform variations?

Current options that I know of for Windows: - DMD/Win32+windbg(1996): This is a version of windbg from 1996 with very basic debugging support and is an embarrassment to be delivered with dmd. - DMD/Win32+cv2pdb: cv2pdb allows conversion of the (often no longer supported) CodeView 4 debug info into pdb files and makes debugging available by most C/C++ debuggers. This is also used by Visual D when using the VS debugger. You can see a list features that work or don't work here: http://dsource.org/projects/cv2pdb/wiki/Features For non-VS debuggers, most of the visualization extras for displaying strings, dynamic and associative arrays will not be available. - DMD/Win32+mago: mago is a debug engine for Visual Studio explicitely for D. Most notably, it has watch support for D expressions whereas in other debuggers you usually have to know the C-representation. It can be used with/without Visual D, but things like the "Auto" window only work with language support by Visual D. - DMD/Win64: dmd emits MS compatible debug information so that the appropriate PDB file is generated during linking and debugging is possible with most C/C++ debuggers. Debug info is not yet optimal, mostly because the VS debugger does not like '.' in names. (cv2pdb defaults to replacing it with ' '). - DMD/Win32+ddbg: ddbg is linked from the web site to http://ddbg.mainia.de/releases.html but this seems a dead link. Last time I tried ddbg some years ago it didn't work out too well for me (maybe it's mostly for D1).

Thanks for the info, that is quite helpful. Though, it does mean that the path for good debugging support in Windows for DMD generated executables, without being tied to an specific IDE (VisualD), doesn't look good.

I'm not that pessimistic. Every decent debugger on Windows understands PDB as there are standard libraries to use them. I guess they can be used (after conveting debug information with cv2pdb for win32) as much as Visual Studio. The visualization addons are specific to VS, though.
 ddbg looks quite dead. I haven't tried it myself recently but I think I
 recall seing some comments for other people as well that it wasn't
 working properly anymore with newer D versions, or something.

 It might be feasable to adapt mago to be used from another IDE. Can a
 command-line interface for it be written? Or is mago too closely tied to
 VisualStudio?

AFAIU the debug engine interface implemented by mago is not strictly tied to Visual Studio, but I'm not sure if other debuggers support it as well. Maybe it is possible to add it as an extension to WinDbg and its friends CDB, NTSD, and KD. It's definitely possible to write your own debugger using it, it's a COM component.
 How about having DMD generate DWARF info on Windows? Is that feasable?
 Is it a lot of work? If DMD does it for Linux, it doesn't seem like it
 should be a lot of work to have that done in Windows as well. I guess it
 would it would have to use GNU tooling on Windows (Cygwin or MSys), but
 that seems quite an acceptable requirement.
 (might that adress some Optlink bugs/limitations as well?)

It's not so difficult to compile dmd to output ELF object files with DWARF debug info instead of OMF though I have never tried to link the result with anything else. I guess there are still OS specifics like calling conventions that are currently tied to the output format.
Sep 26 2013
parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 26/09/2013 09:06, Rainer Schuetze wrote:
 I'm not that pessimistic. Every decent debugger on Windows understands
 PDB as there are standard libraries to use them. I guess they can be
 used (after conveting debug information with cv2pdb for win32) as much
 as Visual Studio. The visualization addons are specific to VS, though.

True, but using those debugging libraries under Java might not be feasible (if they are C# for example), or too much hard work to interface (if they are C/C++ based for example). The ideal interface is a command-line debugger that can be controlled with some IPC interface (stdin/stdout or plain sockets), like GDB and others. I wonder if any decent PDB debuggers support that (and are free). (I haven't looked into that, as for the moment I will focus on GDB support only) -- Bruno Medeiros - Software Engineer
Sep 26 2013
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 26.09.2013 14:30, Bruno Medeiros wrote:
 On 26/09/2013 09:06, Rainer Schuetze wrote:
 I'm not that pessimistic. Every decent debugger on Windows understands
 PDB as there are standard libraries to use them. I guess they can be
 used (after conveting debug information with cv2pdb for win32) as much
 as Visual Studio. The visualization addons are specific to VS, though.

True, but using those debugging libraries under Java might not be feasible (if they are C# for example), or too much hard work to interface (if they are C/C++ based for example). The ideal interface is a command-line debugger that can be controlled with some IPC interface (stdin/stdout or plain sockets), like GDB and others. I wonder if any decent PDB debuggers support that (and are free). (I haven't looked into that, as for the moment I will focus on GDB support only)

CDB is the command line version of WinDbg. IIRC Alex Bothe uses it in his D-IDE as the debugger.
Sep 27 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-23 21:50, Bruno Medeiros wrote:

 (what about Mac though?)

The sate of debugging on Mac OS X is worse than on Linux. There are a couple of problems: * D symbols need to be prefixed with an extra underscore * The GDB system debugger is very old. It doesn't have the D patches the upstream GDB has. Apple is using LLDB as the new system debugger instead, which doesn't have any D patches at all * Line numbers don't work. Probably some issue with incorrect DWARF generated -- /Jacob Carlborg
Sep 23 2013
next sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 24/09/2013 07:19, Jacob Carlborg wrote:
 On 2013-09-23 21:50, Bruno Medeiros wrote:

 (what about Mac though?)

The sate of debugging on Mac OS X is worse than on Linux. There are a couple of problems: * D symbols need to be prefixed with an extra underscore * The GDB system debugger is very old. It doesn't have the D patches the upstream GDB has. Apple is using LLDB as the new system debugger instead, which doesn't have any D patches at all

Ehhh? What's up with Mac OS X and all those outdated operating system managed installations? (I'm referring to the similar issues with had with the JVM) Can't you easily install a newer GDB yourself, outside of Mac OS management? If it can be done even in Windows (with Cygwin or MSYS), surely it can in Mac as well, no?
 * Line numbers don't work. Probably some issue with incorrect DWARF
 generated

What are the implications? Does this mean you canr create a breakpoint for a given source file line? -- Bruno Medeiros - Software Engineer
Sep 25 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-25 16:46, Bruno Medeiros wrote:

 * Line numbers don't work. Probably some issue with incorrect DWARF
 generated

What are the implications? Does this mean you canr create a breakpoint for a given source file line?

Hmm, I was wrong. Line numbers do work, including stack trace and breakpoints. -- /Jacob Carlborg
Sep 26 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-26 09:27, Paolo Invernizzi wrote:

 I can confirm that line numbers are missing from the traces, but at
 least something like:

    (lldb) b test.d:12
    Breakpoint 1: where = test_dmd-head_g`D4test3mooFZi + 8, address =
 0x00000001000013a0

 works correctly, and with tabbed autocompletation of the filename (dmd
 head, OSX 10.9, lldb-300.5.33.1).

I was wrong, line numbers do work for me. Both using DMD 2.063.2 and git HEAD. I'm using Mac OS X 10.8.5 and LLDB-179.5. Works fine in GDB as well. (lldb) r Process 24307 launched: '/Users/jacob/development/d/dlang/dmd/src/main' (x86_64) Process 24307 stopped * thread #1: tid = 0x1c03, 0x00000001000012ef main`D4main3barFZv + 15 at main.d:13, stop reason = EXC_BAD_ACCESS (code=1, address=0x0) frame #0: 0x00000001000012ef main`D4main3barFZv + 15 at main.d:13 10 11 void bar () 12 { -> 13 int* a; 14 auto b = *a; 15 } 16 (lldb) bt * thread #1: tid = 0x1c03, 0x00000001000012ef main`D4main3barFZv + 15 at main.d:13, stop reason = EXC_BAD_ACCESS (code=1, address=0x0) frame #0: 0x00000001000012ef main`D4main3barFZv + 15 at main.d:13 frame #1: 0x00000001000012d9 main`D4main3fooFZv + 9 at main.d:8 frame #2: 0x00000001000012a5 main`_Dmain + 9 at main.d:19 -- /Jacob Carlborg
Sep 26 2013
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 25/09/2013 18:09, Sean Kelly wrote:
 On Sep 25, 2013, at 7:46 AM, Bruno Medeiros <brunodomedeiros+dng gmail.com>
wrote:

 On 24/09/2013 07:19, Jacob Carlborg wrote:
 On 2013-09-23 21:50, Bruno Medeiros wrote:

 (what about Mac though?)

The sate of debugging on Mac OS X is worse than on Linux. There are a couple of problems: * D symbols need to be prefixed with an extra underscore * The GDB system debugger is very old. It doesn't have the D patches the upstream GDB has. Apple is using LLDB as the new system debugger instead, which doesn't have any D patches at all

Ehhh? What's up with Mac OS X and all those outdated operating system managed installations? (I'm referring to the similar issues with had with the JVM) Can't you easily install a newer GDB yourself, outside of Mac OS management? If it can be done even in Windows (with Cygwin or MSYS), surely it can in Mac as well, no?

Probably. But it would be nice if this worked with the compiler that ships with OSX. And for what it's worth, "gcc" on OSX isn't GCC any more either. It's a wrapper around the LLVM C compiler.

Why would that be nice? It saves you the small hassle of downloading GCC+GDB+GDC into it's own installation. With precompiled binaries for your platform, that should take only 15 minutes of your time and then you're set (well, a bit again when you want to update). But having up-to-date tools with up-to-date functionality far outweights in benefits that small hassle. Or are there downsides to that approach? Does using the GCC toolchain on Mac OS X have shortcomings in functionality? The only reasons I can think so far, is if you want to work with LLVM/LLDB specifically (not merely because it's the compiler that ships with OSX, but because you prefer LLDB over GDB). Or if you want to use OSX specific libraries in your D application? (with might somewhat be tied to the OSX toolchain) -- Bruno Medeiros - Software Engineer
Sep 26 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-26 14:22, Bruno Medeiros wrote:

 Why would that be nice? It saves you the small hassle of downloading
 GCC+GDB+GDC into it's own installation. With precompiled binaries for
 your platform, that should take only 15 minutes of your time and then
 you're set (well, a bit again when you want to update).

To avoid what you just listed, that's why it's nice :). Why wouldn't I want to use the default tool chain.
 But having up-to-date tools with up-to-date functionality far outweights in
 benefits that small hassle.

I do have up-to-date tools with with up-to-date functionality, it's just a different tool chain than GCC. Also, I would consider the LLVM tool chain more up-to-date than GCC.
 Or are there downsides to that approach? Does using the GCC toolchain on
 Mac OS X have shortcomings in functionality?  The only reasons I can
 think so far, is if you want to work with LLVM/LLDB specifically (not
 merely because it's the compiler that ships with OSX, but because you
 prefer LLDB over GDB). Or if you want to use OSX specific libraries in
 your D application? (with might somewhat be tied to the OSX toolchain)

As I said, I think that "sudo" is required to run GDB from Macports. That's quite annoying, if that's the case. The GCC tool chain is missing a couple of features which the LLVM tool chain now has. These are mainly C/C++ and Objective-C/C++ features: * Blocks * Modules * A bunch of new Objective-C features * TLS The ones that affect D would be blocks and TLS. It should be possible to use a C function, from D, which uses blocks. One just have to figure out what the runtime representation of a block looks like. In Mac OS X 10.7 Apple introduce native support for TLS. The compiler and linker parts were only implemented in the LLVM tool chain. LDC can take advantage of this. GDC doesn't support native TLS on Mac OS X and, as far as I recall, it doesn't even support emulated TLS which DMD does. I might end up needing a C library that only compiles with the LLVM tool chain. Such as one which uses blocks. I also might want to use Mac OS X specific libraries. GUI applications are a good examples of this. Also, if D is ever going to work in iOS, I think the best bet is on LDC. Because it uses the same tool chain as Apple does. -- /Jacob Carlborg
Sep 26 2013
parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 26/09/2013 16:13, Jacob Carlborg wrote:
 On 2013-09-26 14:22, Bruno Medeiros wrote:

 Why would that be nice? It saves you the small hassle of downloading
 GCC+GDB+GDC into it's own installation. With precompiled binaries for
 your platform, that should take only 15 minutes of your time and then
 you're set (well, a bit again when you want to update).

To avoid what you just listed, that's why it's nice :). Why wouldn't I want to use the default tool chain.

It's just if the 15 minutes setup were the only issue, that's pretty insignificant for any serious development. There are issues and limitations with the D toolchain that are an order of magnitude (maybe even *two* orders) more important/troublesome.
 But having up-to-date tools with up-to-date functionality far
 outweights in
 benefits that small hassle.

I do have up-to-date tools with with up-to-date functionality, it's just a different tool chain than GCC. Also, I would consider the LLVM tool chain more up-to-date than GCC.
 Or are there downsides to that approach? Does using the GCC toolchain on
 Mac OS X have shortcomings in functionality?  The only reasons I can
 think so far, is if you want to work with LLVM/LLDB specifically (not
 merely because it's the compiler that ships with OSX, but because you
 prefer LLDB over GDB). Or if you want to use OSX specific libraries in
 your D application? (with might somewhat be tied to the OSX toolchain)

As I said, I think that "sudo" is required to run GDB from Macports. That's quite annoying, if that's the case.

True, if that's the case.
 The GCC tool chain is missing a couple of features which the LLVM tool
 chain now has. These are mainly C/C++ and Objective-C/C++ features:

 * Blocks
 * Modules
 * A bunch of new Objective-C features
 * TLS

 The ones that affect D would be blocks and TLS.

 It should be possible to use a C function, from D, which uses blocks.
 One just have to figure out what the runtime representation of a block
 looks like.

 In Mac OS X 10.7 Apple introduce native support for TLS. The compiler
 and linker parts were only implemented in the LLVM tool chain. LDC can
 take advantage of this. GDC doesn't support native TLS on Mac OS X and,
 as far as I recall, it doesn't even support emulated TLS which DMD does.

 I might end up needing a C library that only compiles with the LLVM tool
 chain. Such as one which uses blocks.

 I also might want to use Mac OS X specific libraries. GUI applications
 are a good examples of this.

 Also, if D is ever going to work in iOS, I think the best bet is on LDC.
 Because it uses the same tool chain as Apple does.

Blocks is a C language extension by Apple. I suspect that Modules is the same, although I couldn't google it quickly. Therefore this doesn't really affect pure D development. Rather, it's significance would be the same as of the use case of using Mac OS X specific libraries. GDC does not supporting TLS (not even emulated TLS)?? That is a major problem though!! :( It's more than major, it pretty much breaks D development on Mac for anything other than just toy projects (with GDC that is). Well, I'm pretty much conviced anyways: better to support LLDB to have the best debugging support for Mac OS X. I'm not too annoyed since I planned to support LDC/LLDB anyways, as it seems a worthwhile platform/compiler as much as GDC even for other platforms. But it would still have been nice if GDC where to work properly on Mac. -- Bruno Medeiros - Software Engineer
Sep 27 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-09-27 12:52, Bruno Medeiros wrote:

 Blocks is a C language extension by Apple. I suspect that Modules is the
 same, although I couldn't google it quickly. Therefore this doesn't
 really affect pure D development. Rather, it's significance would be the
 same as of the use case of using Mac OS X specific libraries.

Both are LLVM extensions. They're not specific to Mac OS X, but they currently only work on Mac OS X. It's the only platform where they're implemented. As I said, it should be possible to use blocks from D, if one really needs to. I'm also looking at this long term. Hopefully we can use D on iOS one day, that would mean pretty much only use Apple specific API. Also creating a GUI applications usually requires to use platform specific API's. I prefer to write cross-platform code as long as it's possible. But have no problem in using platform specific API's if that enhances the user experience.
 GDC does not supporting TLS (not even emulated TLS)?? That is a major
 problem though!! :( It's more than major, it pretty much breaks D
 development on Mac for anything other than just toy projects (with GDC
 that is).

I have not used GDC myself in a long time. But on all the talks I've seen by Iain Buclaw, he mentions TLS on Mac OS X.
 Well, I'm pretty much conviced anyways: better to support LLDB to have
 the best debugging support for Mac OS X.

Great.
 I'm not too annoyed since I planned to support LDC/LLDB anyways, as it seems a
worthwhile
 platform/compiler as much as GDC even for other platforms. But it would
 still have been nice if GDC where to work properly on Mac.

If you're lucky you can use the same debugging code for GDB and LLDB. Since LLDB is supposed to have many of the GDB commands as aliases. On the other hand LLDB is built as a library so if you really wanted to you could integrate it directly in the plugin. -- /Jacob Carlborg
Sep 27 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-26 20:17, Iain Buclaw wrote:

 I have a sneaky suspicion that it's gcc-4.1 and gdb version that works
 with that compiler that is in macports.  Though that is just heresay - I
 don't /actually/ know.

Macports contains the GCC 4.2 - 4.9 and GDB 7.6 and GDB 6.3.50 with Apple modifications. -- /Jacob Carlborg
Sep 26 2013
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Sep 25, 2013, at 7:46 AM, Bruno Medeiros =
<brunodomedeiros+dng gmail.com> wrote:

 On 24/09/2013 07:19, Jacob Carlborg wrote:
 On 2013-09-23 21:50, Bruno Medeiros wrote:
=20
 (what about Mac though?)

The sate of debugging on Mac OS X is worse than on Linux. There are a couple of problems: =20 * D symbols need to be prefixed with an extra underscore =20 * The GDB system debugger is very old. It doesn't have the D patches =


 upstream GDB has. Apple is using LLDB as the new system debugger
 instead, which doesn't have any D patches at all
=20

Ehhh? What's up with Mac OS X and all those outdated operating system =

with the JVM)
 Can't you easily install a newer GDB yourself, outside of Mac OS =

surely it can in Mac as well, no? Probably. But it would be nice if this worked with the compiler that = ships with OSX. And for what it's worth, "gcc" on OSX isn't GCC any = more either. It's a wrapper around the LLVM C compiler.=
Sep 25 2013
prev sibling next sibling parent "Jacob Carlborg" <doob me.com> writes:
On Wednesday, 25 September 2013 at 14:46:20 UTC, Bruno Medeiros 
wrote:

 Ehhh? What's up with Mac OS X and all those outdated operating 
 system managed installations? (I'm referring to the similar 
 issues with had with the JVM)

Apple has abandoned the GCC tool chain. They're betting all on the LLVM tool chain. That means Clang and LLDB, not GCC and GDB. It's possible the still use the linker from GCC. The issue with JVM is that previously Apple shipped JVM, but since Mac OS X Lion Oracle ships JVM instead. For some reason Eclipse refused to run the JVM shipped by Oracle, this has been reported.
 Can't you easily install a newer GDB yourself, outside of Mac 
 OS management? If it can be done even in Windows (with Cygwin 
 or MSYS), surely it can in Mac as well, no?

Of course you can. It's possible to install using Macports, possibly using Homebrew as well. Although I heard there was some issue with that version of GDB, one need to use sudo. I have not verified that myself. As Sean said, preferably it should work using the standard tool chain, that means LLDB. LLDB is a great debugger which works on other platforms as well (Linux and FreeBSD, 32 and 64bit). LLDB has a completely new command line interface which is more consistent than the one in GDB. It also contains a lot of aliases to GDB commands. If any alias is missing it's possible to create one yourself. I have no idea how to integrate a debugger in an IDE, but if the command line interface is used, you can hopefully use the same interface for GDB and LLDB.
 What are the implications? Does this mean you canr create a 
 breakpoint for a given source file line?

I have tried that. But want I do know is that the stack trace in the debugger doesn't have line numbers. -- /Jacob Carlborg
Sep 25 2013
prev sibling next sibling parent "Jacob Carlborg" <doob me.com> writes:
On Wednesday, 25 September 2013 at 18:34:14 UTC, Jacob Carlborg 
wrote:

 I have tried that.

Should have been: I haven't tried that. -- /Jacob Carlborg
Sep 25 2013
prev sibling next sibling parent "Jacob Carlborg" <doob me.com> writes:
On Wednesday, 25 September 2013 at 17:09:32 UTC, Sean Kelly wrote:

 Probably.  But it would be nice if this worked with the 
 compiler that ships with OSX.  And for what it's worth, "gcc" 
 on OSX isn't GCC any more either.  It's a wrapper around the 
 LLVM C compiler.

Technically it's the GCC fronend using the LLVM backend, but I guess you already know that. -- /Jacob Carlborg
Sep 25 2013
prev sibling next sibling parent "Paolo Invernizzi" <paolo.invernizzi gmail.com> writes:
On Wednesday, 25 September 2013 at 18:34:14 UTC, Jacob Carlborg 
wrote:
 On Wednesday, 25 September 2013 at 14:46:20 UTC, Bruno Medeiros 
 wrote:


 What are the implications? Does this mean you canr create a 
 breakpoint for a given source file line?

I have tried that. But want I do know is that the stack trace in the debugger doesn't have line numbers. -- /Jacob Carlborg

I can confirm that line numbers are missing from the traces, but at least something like: (lldb) b test.d:12 Breakpoint 1: where = test_dmd-head_g`D4test3mooFZi + 8, address = 0x00000001000013a0 works correctly, and with tabbed autocompletation of the filename (dmd head, OSX 10.9, lldb-300.5.33.1). I think some mangling problems are related to the missing underscore in symbols (as David reported), but the big BIG problem is the missing line numbers *sigh* - Paolo Invernizzi
Sep 26 2013
prev sibling next sibling parent "Paolo Invernizzi" <paolo.invernizzi gmail.com> writes:
On Thursday, 26 September 2013 at 08:02:52 UTC, Jacob Carlborg 
wrote:
 On 2013-09-26 09:27, Paolo Invernizzi wrote:

 I can confirm that line numbers are missing from the traces, 
 but at
 least something like:

   (lldb) b test.d:12
   Breakpoint 1: where = test_dmd-head_g`D4test3mooFZi + 8, 
 address =
 0x00000001000013a0

 works correctly, and with tabbed autocompletation of the 
 filename (dmd
 head, OSX 10.9, lldb-300.5.33.1).

I was wrong, line numbers do work for me. Both using DMD 2.063.2 and git HEAD. I'm using Mac OS X 10.8.5 and LLDB-179.5. Works fine in GDB as well. (lldb) r Process 24307 launched: '/Users/jacob/development/d/dlang/dmd/src/main' (x86_64) Process 24307 stopped * thread #1: tid = 0x1c03, 0x00000001000012ef main`D4main3barFZv + 15 at main.d:13, stop reason = EXC_BAD_ACCESS (code=1, address=0x0) frame #0: 0x00000001000012ef main`D4main3barFZv + 15 at main.d:13 10 11 void bar () 12 { -> 13 int* a; 14 auto b = *a; 15 } 16 (lldb) bt * thread #1: tid = 0x1c03, 0x00000001000012ef main`D4main3barFZv + 15 at main.d:13, stop reason = EXC_BAD_ACCESS (code=1, address=0x0) frame #0: 0x00000001000012ef main`D4main3barFZv + 15 at main.d:13 frame #1: 0x00000001000012d9 main`D4main3fooFZv + 9 at main.d:8 frame #2: 0x00000001000012a5 main`_Dmain + 9 at main.d:19

O_o Jacob, you are right: line numbers are ok in lldb stack traces, are missing from the printed d runtime stack trace. So I guess that somehow the d runtime can find that... - Paolo
Sep 26 2013
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--047d7ba975cc535ac804e74d6348
Content-Type: text/plain; charset=ISO-8859-1

On Sep 25, 2013 7:35 PM, "Jacob Carlborg" <doob me.com> wrote:
 On Wednesday, 25 September 2013 at 14:46:20 UTC, Bruno Medeiros wrote:

 Ehhh? What's up with Mac OS X and all those outdated operating system


the JVM)
 Apple has abandoned the GCC tool chain. They're betting all on the LLVM

still use the linker from GCC.

Linker from binutils. :)
 The issue with JVM is that previously Apple shipped JVM, but since Mac OS

JVM shipped by Oracle, this has been reported.
 Can't you easily install a newer GDB yourself, outside of Mac OS


it can in Mac as well, no?
 Of course you can. It's possible to install using Macports, possibly

version of GDB, one need to use sudo. I have not verified that myself.

I have a sneaky suspicion that it's gcc-4.1 and gdb version that works with that compiler that is in macports. Though that is just heresay - I don't /actually/ know. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --047d7ba975cc535ac804e74d6348 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p><br> On Sep 25, 2013 7:35 PM, &quot;Jacob Carlborg&quot; &lt;<a href=3D"mailto:d= oob me.com">doob me.com</a>&gt; wrote:<br> &gt;<br> &gt; On Wednesday, 25 September 2013 at 14:46:20 UTC, Bruno Medeiros wrote:= <br> &gt;<br> &gt;&gt; Ehhh? What&#39;s up with Mac OS X and all those outdated operating= system managed installations? (I&#39;m referring to the similar issues wit= h had with the JVM)<br> &gt;<br> &gt;<br> &gt; Apple has abandoned the GCC tool chain. They&#39;re betting all on the= LLVM tool chain. That means Clang and LLDB, not GCC and GDB. It&#39;s poss= ible the still use the linker from GCC.<br> &gt;</p> <p>Linker from binutils.=A0 :)</p> <p>&gt; The issue with JVM is that previously Apple shipped JVM, but since = Mac OS X Lion Oracle ships JVM instead. For some reason Eclipse refused to = run the JVM shipped by Oracle, this has been reported.<br> &gt;<br> &gt;<br> &gt;&gt; Can&#39;t you easily install a newer GDB yourself, outside of Mac = OS management? If it can be done even in Windows (with Cygwin or MSYS), sur= ely it can in Mac as well, no?<br> &gt;<br> &gt;<br> &gt; Of course you can. It&#39;s possible to install using Macports, possib= ly using Homebrew as well. Although I heard there was some issue with that = version of GDB, one need to use sudo. I have not verified that myself.<br> &gt;</p> <p>I have a sneaky suspicion that it&#39;s gcc-4.1 and gdb version that wor= ks with that compiler that is in macports.=A0 Though that is just heresay -= I don&#39;t /actually/ know. </p> <p>Regards<br> -- <br> Iain Buclaw</p> <p>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;;</p> --047d7ba975cc535ac804e74d6348--
Sep 26 2013
prev sibling next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Monday, 23 September 2013 at 22:57:27 UTC, Iain Buclaw wrote:
 GDB doesn't understand D mangling.  We currently leverage the 
 use of
 setting pretty-print names for debugging purposes, but you 
 require to
 put the names in 'quotation.marks' - I will fix this sometime 
 this year... maybe. :)

Ah, is THAT what was wrong when I fired up my debugger? It would be super awesome if that were documented...somewhere. :/ -Wyatt
Sep 24 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Monday, 23 September 2013 at 23:45:12 UTC, eles wrote:
 On Monday, 23 September 2013 at 19:50:35 UTC, Bruno Medeiros 
 wrote:
 OTOG, simple quetsion: how to install/update DDT plugin to the 
 git HEAD version?

Found that. Could you, please, tag the different releaseed versions, it is helpful when testing for regressions.
Sep 24 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 24 September 2013 14:31, Wyatt <wyatt.epp gmail.com> wrote:
 On Monday, 23 September 2013 at 22:57:27 UTC, Iain Buclaw wrote:
 GDB doesn't understand D mangling.  We currently leverage the use of
 setting pretty-print names for debugging purposes, but you require to
 put the names in 'quotation.marks' - I will fix this sometime this year...
 maybe. :)

Ah, is THAT what was wrong when I fired up my debugger? It would be super awesome if that were documented...somewhere. :/ -Wyatt

As an example, see how I'm using gdb here to get enum values. http://forum.dlang.org/post/mvbkskupmcllcjkmxegw forum.dlang.org Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 24 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 24/09/13 00:57, Iain Buclaw wrote:
 GDB doesn't understand D mangling.  We currently leverage the use of
 setting pretty-print names for debugging purposes, but you require to
 put the names in 'quotation.marks' - I will fix this sometime this
 year... maybe. :)

When I asked about the possibility of adding D support on the Qt Creator mailing lists, one of my respondents remarked:
 Last time I looked the debugging info produced by some D compilers was
 pretty broken. E.g. DMD version 2.058 "encoded" the string[] type as
 "_Array_uns long long". It's hard to base proper debugging on such
 a foundation.

... are we talking about the same mangling issue here?
Sep 24 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 24 September 2013 18:19, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:
 On 24/09/13 00:57, Iain Buclaw wrote:
 GDB doesn't understand D mangling.  We currently leverage the use of
 setting pretty-print names for debugging purposes, but you require to
 put the names in 'quotation.marks' - I will fix this sometime this
 year... maybe. :)

When I asked about the possibility of adding D support on the Qt Creator mailing lists, one of my respondents remarked:
 Last time I looked the debugging info produced by some D compilers was
 pretty broken. E.g. DMD version 2.058 "encoded" the string[] type as
 "_Array_uns long long". It's hard to base proper debugging on such
 a foundation.

... are we talking about the same mangling issue here?

What dmd does is not the same as gdc... :) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 24 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 24/09/13 19:28, Iain Buclaw wrote:
 ... are we talking about the same mangling issue here?

What dmd does is not the same as gdc... :)

I wondered if you'd inherited something from the frontend ... :-)
Sep 24 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 24 September 2013 19:14, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:
 On 24/09/13 19:28, Iain Buclaw wrote:
 ... are we talking about the same mangling issue here?

What dmd does is not the same as gdc... :)

I wondered if you'd inherited something from the frontend ... :-)

Debugging symbols? That is strictly implementation defined. Only thing that comes to the top of my head that have no control over is aliases. These are removed entirely in the front-end so if you have: alias int MyInt; You will see 'MyInt foo' as being type 'int' rather than 'MyInt', but hey, I'm not complaining... :o) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 24 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 25 September 2013 14:45, Bruno Medeiros
<brunodomedeiros+dng gmail.com> wrote:
 On 23/09/2013 23:57, Iain Buclaw wrote:
 On 23 September 2013 20:50, Bruno Medeiros
 <brunodomedeiros+dng gmail.com> wrote:
 I'm looking to begin adding integrated debugger support for the DDT IDE
 pretty soon. With this in mind it would be desirable to have a view of
 what
 level of D language debugger support is there for the various
 combinations
 of platform+compiler+debugger.

 This information would be quite beneficial to regular D users as well, as
 Manu's recent thread on the importance of a debugger is any indication
 of.
 Yet there doesn't seem to be any info about this in the wiki. The
 debuggers
 wiki page ( http://wiki.dlang.org/Debuggers ) doesn't even list the main
 players in this scene (VisualD/Mago, GDB, WinDebugger?)


 I might get started with this, but I would need to enlist the help of
 other
 people for the other platforms/debuggers I don't have proper acess to.

 The only combinations I tried so far was DMD+Windows+GDB, which seems
 like
 it's not supported at all. And GDC+Windows32+GDB which does seem to be
 well
 supported (GDB understands D name mangling, breakpoints in source, D data
 structures layout, etc.). I'm guessing GDC+GDB on Linux works just as
 well.
 (what about Mac though?)

GDB doesn't understand D mangling. We currently leverage the use of setting pretty-print names for debugging purposes, but you require to put the names in 'quotation.marks' - I will fix this sometime this year... maybe. :)

Perhaps I described it incorrectly then. What I mean is that most references and displays of D symbols are made using proper D names, and not mangled names (as you might get if you run it through a pure C/C++ debugger). I've haven't yet seen something like "_D8func_mod5funczFZv" on GDB compiled with GDC.

This is what emitting pretty-print names to the debugger does! Think of it this way, there is a distinction between a decl name, and a decl assembler name. decl name = func.func (this is what is seen by the debugger) decl assember name = _D8func_mod5funczFZv (this is the name of the function emitted in assembler) Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 25 2013
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Wednesday, 25 September 2013 at 14:38:27 UTC, Iain Buclaw 
wrote:
 On 25 September 2013 14:45, Bruno Medeiros
 Perhaps I described it incorrectly then. What I mean is that 
 most references
 and displays of D symbols are made using proper D names, and 
 not mangled
 names (as you might get if you run it through a pure C/C++ 
 debugger). I've
 haven't yet seen something like "_D8func_mod5funczFZv" on GDB 
 compiled with
 GDC.


There is actually (limited) D demangling support in GDB 7. David
Sep 25 2013
prev sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 23/09/2013 20:50, Bruno Medeiros wrote:
 I'm looking to begin adding integrated debugger support for the DDT IDE
 pretty soon. With this in mind it would be desirable to have a view of
 what level of D language debugger support is there for the various
 combinations of platform+compiler+debugger.

 This information would be quite beneficial to regular D users as well,
 as Manu's recent thread on the importance of a debugger is any
 indication of. Yet there doesn't seem to be any info about this in the
 wiki. The debuggers wiki page ( http://wiki.dlang.org/Debuggers )
 doesn't even list the main players in this scene (VisualD/Mago, GDB,
 WinDebugger?)


 I might get started with this, but I would need to enlist the help of
 other people for the other platforms/debuggers I don't have proper acess
 to.

 The only combinations I tried so far was DMD+Windows+GDB, which seems
 like it's not supported at all. And GDC+Windows32+GDB which does seem to
 be well supported (GDB understands D name mangling, breakpoints in
 source, D data structures layout, etc.). I'm guessing GDC+GDB on Linux
 works just as well. (what about Mac though?)

 Several questions remain:
 Is debugger support with DMD+Linux+GDB as good as it is with GDC?
 For DMD+Windows, is there only good debugger support with VisualD? :-(
 And how well does that work with 32/64 bit platform variations?

 It would be great to have these answered, and going forward, keeping
 track of this info in the wiki.

I've updated the Debuggers wiki page with the info gathered so far: http://wiki.dlang.org/Debuggers (I've also added Mono-D and Eclipse CDT to the list of frontends) Feel free to add/modify the information in that page. In particular, a few key missing points: * Is the level of support for DMD-Linux as good as GDC? * What is the level of support for LDC/LLVM? (haven't tried it yet at all) * How complete is the debugging info for DMD-Win64? Is it fully implemented, and/or are there any issues or limitations? (Rainer you are likely the best to answer this one) -- Bruno Medeiros - Software Engineer
Oct 16 2013
next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Wednesday, 16 October 2013 at 12:33:07 UTC, Bruno Medeiros 
wrote:
 Feel free to add/modify the information in that page.

I've added details for the DDD frontend and the WinDbg debugger supplied in the D compiler zip file.
Oct 16 2013
prev sibling next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 16.10.2013 14:33, Bruno Medeiros wrote:
 * How complete is the debugging info for DMD-Win64? Is it fully
 implemented, and/or are there any issues or limitations? (Rainer you are
 likely the best to answer this one)

The stock compiler does not do the replacement ' ' for '.' which confuses the Visual Studio debugger when inspecting class members. The debug info emitted for win64 should more or less be the same as for Win32 (which is only basic to begin with).
Oct 16 2013
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 17.10.2013 08:47, evilrat wrote:
 On Thursday, 17 October 2013 at 06:42:58 UTC, Rainer Schuetze wrote:
 On 16.10.2013 14:33, Bruno Medeiros wrote:
 * How complete is the debugging info for DMD-Win64? Is it fully
 implemented, and/or are there any issues or limitations? (Rainer you are
 likely the best to answer this one)

The stock compiler does not do the replacement ' ' for '.' which confuses the Visual Studio debugger when inspecting class members. The debug info emitted for win64 should more or less be the same as for Win32 (which is only basic to begin with).

i need halp!11 during testing Brad Anderson's dmd beta x64 setup(http://forum.dlang.org/thread/ebrbcdmsothbutakrzsn forum.dlang.org) i've encountered a serious problem, compiled x64 programs works, but i'm totally unable to debug them. what's the problem? (visuald says something like "cannot launch debugger on 'program path', hr=89710016)

please see my reply there.
Oct 17 2013
prev sibling parent "evilrat" <evilrat666 gmail.com> writes:
On Thursday, 17 October 2013 at 06:42:58 UTC, Rainer Schuetze 
wrote:
 On 16.10.2013 14:33, Bruno Medeiros wrote:
 * How complete is the debugging info for DMD-Win64? Is it fully
 implemented, and/or are there any issues or limitations? 
 (Rainer you are
 likely the best to answer this one)

The stock compiler does not do the replacement ' ' for '.' which confuses the Visual Studio debugger when inspecting class members. The debug info emitted for win64 should more or less be the same as for Win32 (which is only basic to begin with).

i need halp!11 during testing Brad Anderson's dmd beta x64 setup(http://forum.dlang.org/thread/ebrbcdmsothbutakrzsn forum.dlang.org) i've encountered a serious problem, compiled x64 programs works, but i'm totally unable to debug them. what's the problem? (visuald says something like "cannot launch debugger on 'program path', hr=89710016)
Oct 16 2013