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

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

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

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

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

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

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

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.

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

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