previously I can use gdb to debug binary generated by dmd; but now (1.009) it reports: Dwarf Error: Cannot find DIE at 0xb705 referenced from DIE at 0x250 when I want to set a bp; or the program seg faults. GNU gdb 6.4-debian
Can you please provide some sample code where this happens?
The issue is still present on 1.017 but here only in a very large program. Im working on a minimal example.
(In reply to comment #1) > Can you please provide some sample code where this happens? > Here's a sample (die.d) that used to work some time ago: void main() { Object foo = null; auto b = foo.toUtf8; } You need dmd 1.0xx (1.016 - 1.018 at least cause this) + tango (I'm using the svn version). You also need to use -g switch. $ dmd -g die.d gcc die.o -o die -g -m32 -Xlinker -L/home/jm/d/dsss/lib -lphobos -lpthread -lm $ gdb die GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /home/jm/tmp/die [Thread debugging using libthread_db enabled] [New Thread -1210349888 (LWP 4919)] Die: DW_TAG_<unknown> (abbrev = 6, offset = 88) has children: FALSE attributes: DW_AT_byte_size (DW_FORM_data1) constant: 8 DW_AT_type (DW_FORM_ref4) constant ref: 80 (adjusted) Dwarf Error: Cannot find type of die [in module /home/jm/tmp/die] (gdb)
Added to DStress as http://dstress.kuehne.cn/norun/d/debug_info_13_A.d (In this case using -gc instead of -g causes the propper gdb behaviour)
(In reply to comment #4) > Added to DStress as > http://dstress.kuehne.cn/norun/d/debug_info_13_A.d > > (In this case using -gc instead of -g causes the proper gdb behaviour) This example triggers the bug with dmd 1.011+ - at least dmd 1.010, 1.009, 1.001 seemed to work fine. GDB version, other compiler flags, runtime lib version (I tried libphobos.a 1.011 with dmd 1.010 too) didn't have any effect.
Created attachment 168 [details] objdump -W binary diff I'm not sure how much this helps, but these are the differences I found in the debugging info between dmd 1.010 and dmd 1.011 generated binaries. The runtime lib is phobos from dmd 1.011 in both binaries and there was no differences in the executable code. Hopefully this gets fixed soon - people need to debug on Linux too.
The change in 1.011 that introduced this was intentional: Extended Dwarf symbolic debug output with DW_TAG_darray_type, DW_TAG_aarray_type, and DW_TAG_delegate types. If you don't use a D aware debugger, then you need to compile with -gc to restrict the dwarf debug output. The issue is on the gdb side in that it doesn't support these DWARF extensions and in fact throws its hands up more spectacularly than it needs to (it could continue past them while still emitting the 'I dont understand' message. So, this falls into the 'not a bug' category. The work around is to use '-gc' rather than just '-g'. The more ideal fix is for someone to get all cozy with gdb to teach it about the new debug info.
I'm reopening this, because these seem to be two separate issues. The original problem still applies. I've been working on an updated patch for GDB 6.7, based on the work available at dsource.org [1]. In addition to the demangler, there's also stubs for the DWARF extensions DMD uses. The simple example Jari-Matti (comment #3) wrote debugs just fine now. However, my larger project still fails with a "Cannot find DIE" error. The original reporter didn't provide a lot of information. But getting a stacktrace from GDB itself where it reports this error in my project, shows the problem to be lying in: DW_TAG_compilation_unit -> DW_TAG_subroutine_type -> DW_TAG_formal_parameter [ DW_AT_type ] The reference in the type attribute isn't completely wild, it points within the .debug_info, but it's still invalid. The dwarfdump [2] utility also trips on this, so I'm again suspecting a problem in DMD. I'm not sure what kind of construct in D generates this kind of output. The D module triggering it contains just 3 classes. I was unable to create a small test case. [1] gdb-patches project: http://www.dsource.org/projects/gdb-patches [2] libdwarf and dwarfdump: http://reality.sgiweb.org/davea/dwarf.html
I looked at the problem again this morning, and it looks like it's triggered by delegate parameters. This is the smallest testcase I could come up with: void problem(void delegate(Object) dg) { dg(null); } void main() { problem(delegate void(Object o) { auto s = o.toString(); }); } There's an intentional crasher again, so simply compiling and running this in GDB should trigger the bug immediately. I tested this with DMD 1.024, Tango 0.99.4 and the GDB 6.7.1 that is in Ubuntu Hardy right now.
Also have this problem with v2.011 on Linux. when setting breakpoint: without -gc: Die: DW_TAG_<unknown> (abbrev = 21, offset = 3690) has children: FALSE attributes: DW_AT_byte_size (DW_FORM_data1) constant: 8 DW_AT_containing_type (DW_FORM_ref4) constant ref: 1553 (adjusted) DW_AT_type (DW_FORM_ref4) constant ref: 3674 (adjusted) Dwarf Error: Cannot find type of die with -gc: Dwarf Error: Cannot find DIE at 0x1369b7 referenced from DIE at 0x19b [in module
BTW, using http://ftp.gnu.org/gnu/gdb/gdb-6.5.tar.bz2 with http://www.dsource.org/projects/gdb-patches d-gdb6.5.patch
This seems to be working in DMD 1.049 and 2.034. I'm trying to organize GDB-related bugs, so I will close this one. Please let me know if I shouldn't be closing bugs and feel free to reopen it if still having this problem.
Seems to be still happening with DMD 2.034 (DMD 1.049 works fine). See bug 3368 for details.
*** Issue 3368 has been marked as a duplicate of this issue. ***
This seems to have something to do with arrays (or manifests itself when they are present): [test]$ cat nolist.d void main() { int i = 0; i++; assert(i == 1); i++; assert(i == 2); i++; assert(i == 3); } That debugs fine, while [test]$ cat list.d void main() { int[] i = new int[1]; i[0]++; assert(i[0] == 1); i[0]++; assert(i[0] == 2); i[0]++; assert(i[0] == 3); } debugging these: [test]$ dgdb -q nolist (gdb) break _Dmain Breakpoint 1 at 0x80490aa: file nolist.d, line 1. (gdb) run Starting program: /home/bernard/src/dmd2/src/test/nolist [Thread debugging using libthread_db enabled] [New Thread 0xb75c46d0 (LWP 27012)] [Switching to Thread 0xb75c46d0 (LWP 27012)] Breakpoint 1, D main () at nolist.d:3 3 int i = 0; Current language: auto; currently d (gdb) quit The program is running. Exit anyway? (y or n) y [test]$ dgdb -q list (gdb) break _Dmain Die: DW_TAG_<unknown> (abbrev = 4, offset = 460) has children: FALSE attributes: DW_AT_byte_size (DW_FORM_data1) constant: 8 DW_AT_type (DW_FORM_ref4) constant ref: 453 (adjusted) Dwarf Error: Cannot find type of die [in module /home/bernard/src/dmd2/src/test/list] (gdb) quit [test]$ gdb -q list (gdb) break _Dmain Die: DW_TAG_<unknown> (abbrev = 4, offset = 460) has children: FALSE attributes: DW_AT_byte_size (DW_FORM_data1) constant: 8 DW_AT_type (DW_FORM_ref4) constant ref: 453 (adjusted) Dwarf Error: Cannot find type of die [in module /home/bernard/src/dmd2/src/test/list] Where `dgdb` is a patch GDB 6.8 and `gdb` is the normal GDB that ships with Jaunty. The `nolist` binary is debuggable with the stock GDB, too.
Oh! The above were simply compiled like so: dmd -g list.d dmd -g nolist.d
Compiling with `-gc` allows gdb to debug it (but not interact with AA or DAs, of course). This is with a patched gdb, though. Perhaps the bug lies in the patches? I have definitely had failures on larger projects with `-gc`, though, so I suspect dmd still has problems with its DWARF output regardless.
http://d.puremagic.com/issues/show_bug.cgi?id=3987 Is related to this bug, if not a duplicate. I'd also like to note that all the DW_TAG_<unknown> errors when using -g rather than -gc are non-bugs, as that is expected until gdb supports D's extensions to DWARF. If you get them when using -gc it is a dmd issue.
Could people having this issue when using -gc try the patch for bug #3987, which seems to fix a lot of issues with gdb. If you are only getting the problem with -g, it is not a bug, you should use -gc until gdb supports the D extensions to dwarf. If it doesn't fix it for you and you can provide a test case, I might be able to fix that issue too.
(In reply to comment #19) > Could people having this issue when using -gc try the patch for bug #3987, > which seems to fix a lot of issues with gdb. If you are only getting the > problem with -g, it is not a bug, you should use -gc until gdb supports the D > extensions to dwarf. If it doesn't fix it for you and you can provide a test > case, I might be able to fix that issue too. I'm getting a Dwarf Error: Cannot find DIE at 0x0 referenced from DIE at 0x3dbf [in module /home/ellery/dxl/bin/dxl] If you feel like wading through my mongo example, here it is: http://personal.utulsa.edu/~ellery-newcomer/dxl.zip http://personal.utulsa.edu/~ellery-newcomer/dmdz.d http://personal.utulsa.edu/~ellery-newcomer/test1.xls build dmdz, then use it to build dxl.zip, then run dxl/bin/dxl test1.xls out.xls Oh, and you need to checkout dmd v1 from repo, as dxl.zip requires changeset 420 to compile. That or fiddle with dxl/read/biff/BOFRecord.d; I think there's only one line of code that needs to be messed with. There, I didn't make it too easy for you, did I?
I'm working on another patch now, another project had a similar issue, which is fixed with my new (incomplete) patch. I'll let you know when I've uploaded it.
Please try the new patch in bug #3987. This fixes debug info for QtD and Bernard Helyer's cases. I don't have a copy of dmd1 set up currently, so if you could try your test case for me that'd be good :) If there are still issues when compiling with -gc after applying the above patch let me know.
(In reply to comment #22) > Please try the new patch in bug #3987. This fixes debug info for QtD and > Bernard Helyer's cases. I don't have a copy of dmd1 set up currently, so if you > could try your test case for me that'd be good :) If there are still issues > when compiling with -gc after applying the above patch let me know. I'm still getting the error message.
Your app causes a different bug to appear, I've reported it as bug #4037, I'll see if I can create a patch for it later today, it should be far simpler to fix than the last one.
With the patches from bugs #3987, #4037 and #4308 applied, I can't reproduce your errors any more Ellery, could you please confirm these patches fix the issue for you? If it does I propose we close this issue and report any future issues as new bugs.
(In reply to comment #25) > With the patches from bugs #3987, #4037 and #4308 applied, I can't reproduce > your errors any more Ellery, could you please confirm these patches fix the > issue for you? If it does I propose we close this issue and report any future > issues as new bugs. erk.. dos2unix dwarf.c.diff but yeah, it looks like it fixes it. Great job!
Closing this bug as fixed, on the basis of that last comment. Report any new issues as new bugs.
AltStyle によって変換されたページ (->オリジナル) / アドレス: モード: デフォルト 音声ブラウザ ルビ付き 配色反転 文字拡大 モバイル