Comment #0 by leandro.lucarella — 2009-07-24T07:40:40Z
This is a meta bug to track the progress on making the GDB patches merge to upstream possible.
The main GDB bug report to include D patches is here:
http://sourceware.org/bugzilla/show_bug.cgi?id=10142
All bugs stopping this from happening should block this one.
Comment #1 by leandro.lucarella — 2009-08-07T20:48:42Z
The Wed, 05 Aug 2009 13:36:49 -0700, Walter sent us (Jason, Mihail and me) a new DMD version to test, trying to address the issues listed in here:
> Try the attached linux executable, which addresses 2604 and 2575.
> Please let me know.
(I'll post the rest of the thread here, with permission)
Comment #2 by leandro.lucarella — 2009-08-07T20:49:22Z
Wed, 05 Aug 2009 20:10:46 -0400, Jason House wrote:
Unfortunately, I don't see an observable change in gdb behavior :(
$ cat main.d
int main(){
enum foo{ bar };
foo x;
final switch(x){ case foo.bar: return 0; }
assert(0); // required due to bugzilla 3229
}
$ dmd2/linux/bin/dmd -g main.d -ofmain
$ gdb main
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(gdb) break main
Breakpoint 1 at 0x80490b7
(gdb) run
Starting program: /home/jhouse/housebot/test/main
[Thread debugging using libthread_db enabled]
[New Thread 0xb7e9a6d0 (LWP 6222)]
[Switching to Thread 0xb7e9a6d0 (LWP 6222)]
Breakpoint 1, 0x080490b7 in main ()
Current language: auto; currently asm
(gdb) list
1 in ../sysdeps/i386/elf/start.S
Comment #3 by leandro.lucarella — 2009-08-07T20:50:18Z
(In reply to comment #2)
Wed, 05 Aug 2009 21:36:36 -0700, Walter Bright wrote:
I didn't think changing the MIPS tag would fix it, but it's a start. I also removed the children from the MODULE tag. What's next?
Comment #4 by leandro.lucarella — 2009-08-07T20:51:41Z
(In reply to comment #1)
Walter Bright wrote (Wed, 05 Aug 2009 22:42:19 -0700):
Fixed a problem with dwarf output.
Comment #5 by leandro.lucarella — 2009-08-07T20:53:52Z
Created attachment 436
LDC debug output
(In reply to comment #4)
Jason House wrote (Thu, 06 Aug 2009 07:55:55 -0400):
No luck with gdb. Here's something interesting though:
$ dmd2/linux/bin/dmd -g main.d -ofmain
$ objdump -g main > info.dmd
objdump: Warning: .debug_info offset of 0x12c in .debug_pubnames section
does not point to a CU header.
$ ldc-0.9.1-x86_32/bin/ldc -g main.d
$ objdump -g main > info.ldc
objdump: Warning: Bogus end-of-siblings marker detected at offset 226
in .debug_info section
objdump: Warning: Bogus end-of-siblings marker detected at offset 227
in .debug_info section
objdump: Warning: Bogus end-of-siblings marker detected at offset 228
in .debug_info section
objdump: Warning: Further warnings about bogus end-of-sibling markers
suppressed
When comparing the output, I do see that ldc outputs dw_at_subprogram
when dmd outputs dw_at_module. I think it's safe to ignore that ldc
outputs _D4main16__moduleinfoCtorZ and dmd does not.
I see this in the ldc output but not dmd:
DW_AT_MIPS_linkage_name DW_FORM_string
DW_AT_decl_file DW_FORM_data1
DW_AT_decl_line DW_FORM_data1
DW_AT_low_pc DW_FORM_addr
DW_AT_high_pc DW_FORM_addr
DW_AT_frame_base DW_FORM_block1
I also see
DW_AT_decl_line DW_FORM_data1 (in ldc)
DW_AT_decl_line DW_FORM_data2 (in dmd)
There's a few other differences, but I nievely thing they're either
trivial or related to the above. LDC outputs a few "identical" tags in
a slightly different order. I can provide details on that if it'd help.
Comment #6 by leandro.lucarella — 2009-08-07T20:54:55Z
Created attachment 437
DMD debug output
(Part of comment #4)
Comment #7 by leandro.lucarella — 2009-08-07T20:55:46Z
(In reply to comment #5)
Jason House wrote (Thu, 6 Aug 2009 08:20:17 -0400):
I should add main.d is "void main(){}"
Comment #8 by leandro.lucarella — 2009-09-03T17:31:38Z
The latest patch were sent to gdb-patches. Mihail is waiting for the legal GDB papers to sign them, John Demme seems to be lost again :(
Comment #9 by leandro.lucarella — 2009-09-15T18:50:52Z
John Demme has told me today that he signed the copyright assignment, so we one (big) step forward =)
Comment #10 by leandro.lucarella — 2009-11-17T16:56:27Z
Mihail Zenkov just told me he finally received the papers and he will send them back signed today.
Great news!
Comment #11 by leandro.lucarella — 2010-01-09T17:06:57Z
Comment #12 by leandro.lucarella — 2010-04-22T19:59:57Z
It looks like all the paperwork is finally done (not confirmed though), and Mihail is still working on the patch and merge, fixing the stuff that comes from the review of the patch done by the GDB developers.
Comment #13 by leandro.lucarella — 2010-04-23T07:39:00Z
The last thread in the review process is here:
http://thread.gmane.org/gmane.comp.gdb.patches/57197
From this:
Mihail> Sorry for too very long delay. I fix patch as you and Joel
Mihail> suggested, i hope it ready for inclusion.
It is very close. In fact, I think I only saw formatting nits.
Thanks for working on this.
I think this bug is very close to be closed ;)
Comment #14 by leandro.lucarella — 2010-04-28T09:21:07Z
As of Thu, 29 Apr 2010 14:45:37 +0000, the D patches have been approved and pushed upstream!
http://sourceware.org/git/?p=gdb.git;a=commit;h=870850ddab624f9d0111a4a0733cf7f5edf9bf91
This means gdb 7.2 and above will have D support built in =)
The current patch does demangling and makes sure strings are handled correctly, it does not add support for D extensions (so compiling with -gc is still required for now).
Comment #16 by leandro.lucarella — 2010-04-29T13:40:21Z
I (happily) think that this bug can be closed now, and since I opened it, I will :).
Any other thing that needs tracking about improving the D support in GDB (like supporting the D extensions) can be done in another bug report.