Jason House wrote:
> there's already someone working on getting that patch into gdb.

Great!

> I've
> been trying lately to play with the dmd -gc output so that gdb
> recognizes it properly.

dumpobj will pretty-print the compiler debug output. It's a handy tool.

> I'm not very far, and my queries in #gdb have
> gone unanswered :(

That's normal. But the source to GDB is available, and that's usually a lot better source of information. I prefer it to asking questions and getting incorrect answers back :-(

Walter Bright Wrote:

> Jason House wrote:
> > there's already someone working on getting that patch into gdb.
> 
> Great!
> 
> > I've
> > been trying lately to play with the dmd -gc output so that gdb
> > recognizes it properly.
> 
> dumpobj will pretty-print the compiler debug output. It's a handy tool.

Any tips/links on usage and output interpretation would be appreciated. I've never read the dwarf spec and have no idea what should be in debug info.

> > I'm not very far, and my queries in #gdb have
> > gone unanswered :(
> 
> That's normal. But the source to GDB is available, and that's usually a lot better source of information. I prefer it to asking questions and getting incorrect answers back :-(

the last time someone helped me on #gdb, they were extremely helpful and knowledgable. I'm hoping for a similar experience. It'd likely speed up my efforts 5 fold. I won't hold my breath though.

Jason House wrote:
> there's already someone working on getting that patch into gdb. I've been trying lately to play with the dmd -gc output so that gdb recognizes it properly. I'm not very far, and my queries in #gdb have gone unanswered :(

You could also try compiling the same file with DMD and LDC and compare the debug info.

Jason House wrote:
> Walter Bright Wrote:
> 
>> Jason House wrote:
>>> there's already someone working on getting that patch into gdb.
>> Great!
>> 
>>> I've been trying lately to play with the dmd -gc output so that
>>> gdb recognizes it properly.
>> dumpobj will pretty-print the compiler debug output. It's a handy
>> tool.
> 
> Any tips/links on usage and output interpretation would be
> appreciated. I've never read the dwarf spec and have no idea what
> should be in debug info.

Not really. I developed it by reading the spec and trying to dump the output of gcc.

> 
>>> I'm not very far, and my queries in #gdb have gone unanswered :(
>> That's normal. But the source to GDB is available, and that's
>> usually a lot better source of information. I prefer it to asking
>> questions and getting incorrect answers back :-(
> 
> the last time someone helped me on #gdb, they were extremely helpful
> and knowledgable. I'm hoping for a similar experience. It'd likely
> speed up my efforts 5 fold. I won't hold my breath though.
> 

Walter Bright wrote:
> yigal chripun wrote:
>> Lars T. Kyllingstad Wrote:
>>
>>> yigal chripun wrote:
>>>> Either you need to have a plan or you need to have a community
>>>> driven process (Java JSRs, Python PEPs).
>>> There is a similar option for D, although it doesn't have a fancy abbreviation: You can put enhancement requests in Bugzilla and get
>>>  people to vote for them.
>>>
>>> -Lars
>>
>> you must be kidding right? maybe the situation is improving lately
>> but not that long ago I remember posts by downs where he pointed out
>> an old bug in DMD with a patch to fix that bug already in Bugzilla
>> and that fix was in bugzila several *years* without anyone caring.
> 
> If that is the bug I am thinking of, the patch papered over one instance of the problem and didn't fix it at all. The patch even noted that it was incomplete. The real fix required much more extensive work, and there were higher priority problems.
> 
> My general experience with posted compiler patches is about half of them are good, the other half are incorrect and require more development.
> 
> For a more recent example, 3122 contained a patch that was marked as complete and tested, but it had two serious bugs (did not check that a filename was supplied, and did not check for file write errors) and an unnecessary hardcoded OS dependency (on path lengths). These aren't hard to fix, and I merged in the patch with fixes, I'm just trying to say that things are not as simple as just apply patches.
> 
> That said, I still appreciate and encourage posting patches to bugzilla, as even if incomplete they still cut down the work for me that is necessary to fix the problem, and hence they are valuable.

It'd be good to have a keyword in bugzilla, "patch-rejected", which you could use if there's a problem with a patch and you aren't going to include it in the next release. Then, such cases wouldn't keep showing up on a search for all 'patch' bugs, and patch contributers could check for them, redoing their patch if desired.

Another useful keyword would be "no-line-number". Error messages with no line number are high severity (almost as important as compiler crashes), but they're hard to track right now.

This would give the bug severity list as:

patch
wrong-code
ice-on-valid-code
ice-on-invalid-code
no-line-number
rejects-valid
accepts-invalid
diagnostic

Currently, 'patch' is one of the biggest categories in bugzilla! <g>.

Walter Bright Wrote:

> yigal chripun wrote:
> > Lars T. Kyllingstad Wrote:
> > 
> >> yigal chripun wrote:
> >>> Either you need to have a plan or you need to have a community driven process (Java JSRs, Python PEPs).
> >> There is a similar option for D, although it doesn't have a fancy
> >> abbreviation: You can put enhancement requests in Bugzilla and get
> >>  people to vote for them.
> >> 
> >> -Lars
> > 
> > you must be kidding right? maybe the situation is improving lately but not that long ago I remember posts by downs where he pointed out an old bug in DMD with a patch to fix that bug already in Bugzilla and that fix was in bugzila several *years* without anyone caring.
> 
> If that is the bug I am thinking of, the patch papered over one instance of the problem and didn't fix it at all. The patch even noted that it was incomplete. The real fix required much more extensive work, and there were higher priority problems.
> 
> My general experience with posted compiler patches is about half of them are good, the other half are incorrect and require more development.
> 
> For a more recent example, 3122 contained a patch that was marked as complete and tested, but it had two serious bugs (did not check that a filename was supplied, and did not check for file write errors) and an unnecessary hardcoded OS dependency (on path lengths). These aren't hard to fix, and I merged in the patch with fixes, I'm just trying to say that things are not as simple as just apply patches.
> 
> That said, I still appreciate and encourage posting patches to bugzilla, as even if incomplete they still cut down the work for me that is necessary to fix the problem, and hence they are valuable.

the above implementation details are completely besides the point.
and to re-iterate:
the point being that there was a bug report with a patch lying around for 1.5 *years* without any kind of _response_.

Christian Kamm wrote:

> Jason House wrote:
>> there's already someone working on getting that patch into gdb. I've been trying lately to play with the dmd -gc output so that gdb recognizes it properly. I'm not very far, and my queries in #gdb have gone unanswered :(
> 
> You could also try compiling the same file with DMD and LDC and compare the debug info.

It's a good idea.

Something really strange happened though.  In order to get ldc to work, I had to install libelf.  When I did that, the debug info from dmd changed drastically.  I wonder how/why that happened.

After the install, I get this error from objdump when examing the dmd
output:
objdump: Warning: .debug_info offset of 0x12c in .debug_pubnames section
does not point to a CU header.