Re: Debugging support for D - wiki
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).
Re: Debugging support for D - wiki
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/ebrbcdmsothbutakr...@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)
Re: Debugging support for D - wiki
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/ebrbcdmsothbutakr...@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.
Re: Debugging support for D - wiki
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
Re: Debugging support for D - wiki
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.
Re: Debugging support for D - wiki
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
Re: Debugging support for D - wiki
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
Re: Debugging support for D - wiki
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.
Re: Debugging support for D - wiki
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 = 0x000113a0 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
Re: Debugging support for D - wiki
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
Re: Debugging support for D - wiki
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 =
0x000113a0
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, 0x000112ef main`D4main3barFZv + 15 at
main.d:13, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x000112ef main`D4main3barFZv + 15 at main.d:13
10
11 void bar ()
12 {
- 13int* a;
14 auto b = *a;
15 }
16
(lldb) bt
* thread #1: tid = 0x1c03, 0x000112ef main`D4main3barFZv + 15 at
main.d:13, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x000112ef main`D4main3barFZv + 15 at main.d:13
frame #1: 0x000112d9 main`D4main3fooFZv + 9 at main.d:8
frame #2: 0x000112a5 main`_Dmain + 9 at main.d:19
--
/Jacob Carlborg
Re: Debugging support for D - wiki
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.
Re: Debugging support for D - wiki
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 =
0x000113a0
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, 0x000112ef
main`D4main3barFZv + 15 at main.d:13, stop reason =
EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x000112ef main`D4main3barFZv + 15 at
main.d:13
10
11 void bar ()
12 {
- 13int* a;
14 auto b = *a;
15 }
16
(lldb) bt
* thread #1: tid = 0x1c03, 0x000112ef
main`D4main3barFZv + 15 at main.d:13, stop reason =
EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x000112ef main`D4main3barFZv + 15 at
main.d:13
frame #1: 0x000112d9 main`D4main3fooFZv + 9 at
main.d:8
frame #2: 0x000112a5 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
Re: Debugging support for D - wiki
On 25/09/2013 18:09, Sean Kelly wrote: On Sep 25, 2013, at 7:46 AM, Bruno Medeiros brunodomedeiros+...@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
Re: Debugging support for D - wiki
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
Re: Debugging support for D - wiki
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
Re: Debugging support for D - wiki
On Sep 25, 2013 7:35 PM, Jacob Carlborg d...@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 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. Linker from binutils. :) 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. 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';
Re: Debugging support for D - wiki
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
Re: Debugging support for D - wiki
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
Re: Debugging support for D - wiki
On 23/09/2013 23:57, Iain Buclaw wrote: On 23 September 2013 20:50, Bruno Medeiros brunodomedeiros+...@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
Re: Debugging support for D - wiki
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
Re: Debugging support for D - wiki
On 25 September 2013 14:45, Bruno Medeiros brunodomedeiros+...@gmail.com wrote: On 23/09/2013 23:57, Iain Buclaw wrote: On 23 September 2013 20:50, Bruno Medeiros brunodomedeiros+...@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';
Re: Debugging support for D - wiki
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
Re: Debugging support for D - wiki
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
Re: Debugging support for D - wiki
On Sep 25, 2013, at 7:46 AM, Bruno Medeiros brunodomedeiros+...@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.
Re: Debugging support for D - wiki
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
Re: Debugging support for D - wiki
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
Re: Debugging support for D - wiki
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
Re: Debugging support for D - wiki
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. This is what emitting pretty-print names to the debugger does! There is actually (limited) D demangling support in GDB 7. David
Re: Debugging support for D - wiki
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
Re: Debugging support for D - wiki
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
Re: Debugging support for D - wiki
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
Re: Debugging support for D - wiki
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.
Re: Debugging support for D - wiki
On 24 September 2013 14:31, Wyatt wyatt@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/mvbkskupmcllcjkmx...@forum.dlang.org Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Debugging support for D - wiki
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?
Re: Debugging support for D - wiki
On 24 September 2013 18:19, Joseph Rushton Wakeling joseph.wakel...@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';
Re: Debugging support for D - wiki
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 ... :-)
Re: Debugging support for D - wiki
On 24 September 2013 19:14, Joseph Rushton Wakeling joseph.wakel...@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';
Re: Debugging support for D - wiki
What about Win64 and VS Debugger?
Re: Debugging support for D - wiki
On 23 September 2013 20:50, Bruno Medeiros brunodomedeiros+...@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';
Re: Debugging support for D - wiki
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?
