Debugging support for D - wiki

[Bruno Medeiros]

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