This is to fix the unittest and dwarf screwups in the last release.

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.060.zip


http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.045.zip

On 04/05/10 18:30, Walter Bright wrote:
> This is to fix the unittest and dwarf screwups in the last release.
>
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.060.zip
>
>
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.045.zip

Thanks a lot for prioritizing this and getting it fixed :) Debugging D on linux is now bearable, and even a pleasant experience at times =)

Still a long way to go though, various (much!) smaller issues that need fixing... If no one else gets to them I'll go on a debug fixing spree at some point in a couple of months and see if we can't get bug #4044 (debugging tracker) closed :)

On Tue, May 04, 2010 at 10:30:36AM -0700, Walter Bright wrote:
> This is to fix the unittest and dwarf screwups in the last release.

Yay, it seems to have fixed the weird endless loop I got in the last one.

Robert Clipsham wrote:
> Still a long way to go though, various (much!) smaller issues that need fixing... If no one else gets to them I'll go on a debug fixing spree at some point in a couple of months and see if we can't get bug #4044 (debugging tracker) closed :)

I agree that getting all the gdb issues sorted out will be a nice win.

On 04/05/10 18:52, Walter Bright wrote:
> I agree that getting all the gdb issues sorted out will be a nice win.

I fixed all the killer ones (for ELF systems at least), you can now set breakpoints and get backtraces etc, the remaining issues are to do with line numbers being a bit off under certain circumstances, code listing not working in gdb (I've never used this feature, hehe) and a few enhancements.

This said, debugging on OS X is currently impossible, I should be able to take a look at that some time soon.

While you're reading, is there any chance you could take a look at my post on the dmd-internals ML and give me some feedback? I noticed you agreed with Brad in a bug report, but to what extent? When I get around to fixing all those bugs I'd like to know where you stand so I can work on some enhancements to debug info as well as just bug fixes :)

Robert Clipsham wrote:
> While you're reading, is there any chance you could take a look at my post on the dmd-internals ML and give me some feedback? I noticed you agreed with Brad in a bug report, but to what extent? When I get around to fixing all those bugs I'd like to know where you stand so I can work on some enhancements to debug info as well as just bug fixes :)

Basically, I don't think the switches need to change, just:

-g: debugger can handle D data types and extensions

-gc: make it work with whatever the debugger can handle, i.e. for debuggers that don't know about D

On 04/05/10 19:03, Walter Bright wrote:
> Basically, I don't think the switches need to change, just:
>
> -g: debugger can handle D data types and extensions
>
> -gc: make it work with whatever the debugger can handle, i.e. for
> debuggers that don't know about D

You'd be ok with, for example:
  -g             add symbolic debug info
  -gc            add symbolic debug info, pretend to be C++

Instead of C then? Or some other language that debuggers support? I say this as C++ supports more of D's features, so we'd be able to give better debugging info for debuggers without explicit D support.

There was another point in that post, about the D extensions to DWARF... I think it is unlikely that patches to support D's extensions to DWARF would be accepted into gdb, particularly as the values for the DW_TAG's conflicts with things in the DWARF4 spec. I think there should be a way to act like D but without these extensions. Ideally the solution to this is to try and get the extensions officially into the DWARF spec, which I'd be willing to push for if possible.

Robert Clipsham wrote:
> You'd be ok with, for example:
>   -g             add symbolic debug info
>   -gc            add symbolic debug info, pretend to be C++
> 
> Instead of C then? Or some other language that debuggers support? I say this as C++ supports more of D's features, so we'd be able to give better debugging info for debuggers without explicit D support.

Yes.

> There was another point in that post, about the D extensions to DWARF... I think it is unlikely that patches to support D's extensions to DWARF would be accepted into gdb, particularly as the values for the DW_TAG's conflicts with things in the DWARF4 spec. I think there should be a way to act like D but without these extensions. Ideally the solution to this is to try and get the extensions officially into the DWARF spec, which I'd be willing to push for if possible.

That's the problem with D extensions; unless they get officially adopted they conflict with future changes to the spec. We need to get them officially adopted.

On 04/05/10 19:50, Walter Bright wrote:
> That's the problem with D extensions; unless they get officially adopted
> they conflict with future changes to the spec. We need to get them
> officially adopted.

Too late for this, DWARF 4 has introduced conflicts with them already. We could try and get them pushed for dwarf 4, but if they get in the values of the tags will have to change (not really a problem, as only one debugger supports them I think, and to my knowledge it isn't widely used for D yet... So we'd be able to talk to the developers and work around this). I'd be willing to take action to get them pushed for DWARF 4 or (if it's too late for that) DWARF 5, if that's OK with you?

On Tue, 4 May 2010, Robert Clipsham wrote:

> On 04/05/10 19:50, Walter Bright wrote:
> > That's the problem with D extensions; unless they get officially adopted they conflict with future changes to the spec. We need to get them officially adopted.
> 
> Too late for this, DWARF 4 has introduced conflicts with them already. We could try and get them pushed for dwarf 4, but if they get in the values of the tags will have to change (not really a problem, as only one debugger supports them I think, and to my knowledge it isn't widely used for D yet... So we'd be able to talk to the developers and work around this). I'd be willing to take action to get them pushed for DWARF 4 or (if it's too late for that) DWARF 5, if that's OK with you?

I've lost track of the details of the extensions that are in use.  I assume they're to cover the array and dictionary layouts.  I wouldn't be suprised if there wasn't coverage for them in the current dwarf formats, or close enough to make them work.

Another potential path, that would obviously be gdb specific, is to include some scripts that help display the more complex types.  I saw something about gdb/python integration.  A little bit of scripting can go a long long way.

Later,
Brad