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

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

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

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

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

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

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

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

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

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.