January 10, 2009

           Summary: gdb can not show code
           Product: D
           Version: 2.022
          Platform: PC
               URL: http://pastebin.com/m21fab94f
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: jason.james.house@gmail.com

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(){}


January 24, 2009

------- Comment #1 from jason.james.house@gmail.com  2009-01-24 11:16 -------
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.


January 24, 2009

------- Comment #2 from mihail.zenkov@gmail.com  2009-01-24 16:09 -------
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
 <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


February 08, 2009

------- Comment #3 from mihail.zenkov@gmail.com  2009-02-07 20:56 -------
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)


February 15, 2009

jason.james.house@gmail.com changed:

           What    |Removed                     |Added
                   |f                           |
           Severity|normal                      |major
            Version|2.022                       |2.025

------- Comment #4 from jason.james.house@gmail.com  2009-02-15 10:00 -------
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


February 20, 2009

------- Comment #5 from bugzilla@digitalmars.com  2009-02-20 04:42 -------
But dmd does emit the low_pc and high_pc data. Compile:

int foo(int i) { return i * i; }


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.


February 20, 2009

------- Comment #6 from jason.james.house@gmail.com  2009-02-20 07:54 -------
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 :(


February 25, 2009

------- Comment #7 from bugzilla@digitalmars.com  2009-02-25 00:30 -------
Looks like DW_AT_MIPS_linkage_name is an undocumented vendor extension to Dwarf.


February 26, 2009

------- Comment #8 from mihail.zenkov@gmail.com  2009-02-25 20:46 -------
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."


August 05, 2009

--- Comment #9 from Walter Bright <bugzilla@digitalmars.com>  2009-08-05 01:21:42 PDT ---
I'll add the MIPS_linkage tag and change the name tag. We'll see how far that gets us.

Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home