Bug 2575 – gdb: can not show code

The URL shows how this bug typically manifests itself. GDB seems to look for .s files for assembly code and can't seem to find them. This behavior exhibits itself with all D2 programs I've tried, including void main(){}

After a lot of help from volodya on irc #gdb, it looks like the issue is that the low_pc and high_pc attributes are missing. GDB can try to compensate for this (as if it was some legacy producer of debug info) by walking the children, but it only looks at "namespace" and "subprogram". D has "module" which stops it.

Break points don't work with demangled name. Not sure but imho problem in incorrect DW_AT_name and/or not provided DW_AT_MIPS_linkage by DMD. DMD put mangled name to DW_AT_name: <2><91>: Abbrev Number: 6 (DW_TAG_subprogram) DW_AT_sibling : <c8> DW_AT_name : _D5crash3fooFZv DW_AT_decl_file : 1 DW_AT_decl_line : 12 DW_AT_low_pc : 0 DW_AT_high_pc : 0x16 DW_AT_frame_base : 1 byte block: 55 (DW_OP_reg5) GDC/GCC put mangled name to DW_AT_MIPS_linkage_name and demandled to DW_AT_name: <1><bd>: Abbrev Number: 6 (DW_TAG_subprogram) DW_AT_external : 1 DW_AT_name : foo DW_AT_decl_file : 1 DW_AT_decl_line : 12 DW_AT_MIPS_linkage_name: _D5crash3fooFZv DW_AT_low_pc : 0x3b DW_AT_high_pc : 0x51 DW_AT_frame_base : 0x43 (location list) After fix DW_TAG_module you can try use mangled name, for example main - _Dmain

GDB also work fine with LDC debug info. <1><a7>: Abbrev Number: 3 (DW_TAG_subprogram) DW_AT_name : crash.foo DW_AT_MIPS_linkage_name: _D5crash3fooFZv DW_AT_external : 1 DW_AT_prototyped : 1 DW_AT_decl_file : 1 DW_AT_decl_line : 11 DW_AT_low_pc : 0x20 DW_AT_high_pc : 0x21 DW_AT_frame_base : 1 byte block: 54 (DW_OP_reg4)

It looks like the URL showing the problem has expired. Here's a sample session. I upped the severity because this is a really painful bug in dmd for me. I'm forced to place tons of writefln statements into the code instead of being able to step through it in the debugger jhouse@jhouse-laptop:~/housebot/0.8$ gdb ./housebot-0.8 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 0x8059e87 (gdb) run Starting program: /home/jhouse/housebot/0.8/housebot-0.8 [Thread debugging using libthread_db enabled] [New Thread 0xb7c3eb00 (LWP 23503)] [Switching to Thread 0xb7c3eb00 (LWP 23503)] Breakpoint 1, 0x08059e87 in main () Current language: auto; currently asm (gdb) list 1 /tmp/ccPssJzP.s: No such file or directory. in /tmp/ccPssJzP.s (gdb) quit The program is running. Exit anyway? (y or n) y jhouse@jhouse-laptop:~/housebot/0.8$

But dmd does emit the low_pc and high_pc data. Compile: int foo(int i) { return i * i; } with: dmd -c -g foo.d Then run dumpobj on it: dumpobj -p foo.o which will pretty-print the dwarf debug into. The attributes are there.

D'oh, if only I reported more information when I remembered it. Trying now, I'm doing "objdump -Wgs <executable>" and then searching for module. What I see right before it is DW_TAG_compile_unit. I don't see DW_AT_high_pc and DW_AT_low_pc in that section, but I don't know if it's supposed to be there. The impression I got from my chats on #gdb was that the debug data was stored in somewhat of a hierarchical structure. In order to figure out the offsets for the source file, it wanted to find the high and low attributes but did not. There's a workaround inside gdb that will walk the children in order to get around the behavior of old compilers, but it's fragile. Having modern stuff such as DW_TAG_module stops it from operating (since it doesn't match what old compilers did). That's all I can remember/reproduce with some experimentation with objdump. Can you reproduce the problem? Maybe chat with someone on #gdb? I had to wait ~12 hours to get a response. Once I did, they were very helpful. I'll guess the compile_unit should have high_pc and low_pc, but I'm only guessing. If you can reproduce the issue, then it should be easy to see if what you did works or not. Sorry for the lack of detail :(

Looks like DW_AT_MIPS_linkage_name is an undocumented vendor extension to Dwarf.

It undocumented but widely used. IMHO better use them for mangled name than DW_AT_name. Current way violates DWARF: "Because the names of program objects described by DWARF are the names as they appear in the source program, implementations of language translators that use some form of mangled name (as do many implementations of C++) should use the unmangled form of the name in the DWARF DW_AT_name attribute, including the keyword operator (in names such as “operator +”), if present. Sequences of multiple whitespace characters may be compressed."

I'll add the MIPS_linkage tag and change the name tag. We'll see how far that gets us.

Fixed dmd 1.047 and 2.032

This is not entirely fixed for DMD 2, see bug 3368.

Woops! Closing it again since it doesn't look like the same problem. The bug I meant to reopen was bug 1079.