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

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

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
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';

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

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

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

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.

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

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.

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