http://d.puremagic.com/issues/show_bug.cgi?id=3987

           Summary: [gdb] Invalid DWARF output for function pointers
           Product: D
           Version: 1.055
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: robert@octarineparrot.com


--- Comment #0 from Robert Clipsham <robert@octarineparrot.com> 2010-03-19 16:18:50 PDT ---
The following program causes dmd to produce invalid DWARF output, rendering the program impossible to debug with gdb:
----
void function() myfunc;
void main(){}
----
When compiled with either -g or -gc, causes this error in gdb when setting a breakpoint (eg b _Dmain):
----
Die: DW_TAG_padding (abbrev = 0, offset = 0)
        has children: FALSE
        attributes:
Dwarf Error: Cannot find type of die [in module /tmp/test]
----
From what I can gather, the DWARF output is correct (objdump --dwarf gives no errors), but the padding before .debug_info is incorrect, causing gdb to be unable to read it properly.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3987



--- Comment #1 from Robert Clipsham <robert@octarineparrot.com> 2010-03-27 12:01:39 PDT ---
Compile with:
$ dmd -c -gc test.d
$ gcc test.o -o test -m32
(Note: I had a dmd.conf in the same directory to make sure druntime/phobos
weren't included, I don't know if this is needed)
----
void function() foobar;
extern(C)void _Dmodule_ref(){}
extern(C)int main(int argc, char** argv)
{
        return 0;
}
//void foo(){}
//void main(){}
----
Uncommenting either of the 2 functions at the bottom will trigger the bug, but
without them it does not happen. I have attached 3 files, which are the outputs
of the following 3 commands:
$ objdump --dwarf test > dwarf2
$ objdump --dwarf test > dwarf # With void main(){}
$ diff -u dwarf2 dwarf
Hopefully this should help figure out what's happening. Without reading into
the DWARF spec I cannot figure out what's wrong, but there's not a huge amount
of difference between them, so it shouldn't take too much effort for someone
who knows the spec to figure out what's wrong. The above was tested with dmd
2.042.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3987



--- Comment #2 from Robert Clipsham <robert@octarineparrot.com> 2010-03-27 12:12:48 PDT ---
For some unknown reason (probably PEBKAC), the attachments were added to the
wrong ticket... See:
# objdump --dwarf test > dwarf
http://d.puremagic.com/issues/attachment.cgi?id=590
# objdump --dwarf test > dwarf2
http://d.puremagic.com/issues/attachment.cgi?id=591
# diff -u dwarf2 dwarf
http://d.puremagic.com/issues/attachment.cgi?id=592

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3987



--- Comment #3 from Robert Clipsham <robert@octarineparrot.com> 2010-03-28 07:37:29 PDT ---
I've picked up on this again today, and it seems the debug info produced is wrong either way...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3987



--- Comment #4 from Robert Clipsham <robert@octarineparrot.com> 2010-03-29 14:28:51 PDT ---
I've found the issue. In backend/dwarf.c:dward_typidx(), there is a switch statement which switches on the basic type for the current type. For a function pointer, this is a pointer, so the debug info for a pointer is generated. dmd tries to select the type the pointer is pointing to, (for int* it would be int for example) and seems to select the wrong value for function pointers. Comparing the debug output with that of clang, it seems that the DW_AT_type is not needed for function pointers. Commenting out lines 1210, 1328, 1329 and 1386 (in dmd 2.042, may be different for other versions) fixes the debug info and all is well. Of course this breaks debug info for normal pointer types, so a special case needs to be made.
----
void function() foobar;
extern(C)void _Dmodule_ref(){}
extern(C)int main(int argc, char** argv)
{
        return 0;
}
----
When compiled with dmd -gc test.d, the debug info is as follows (irrelevant
parts removed):
.debug_info:
 <1><4b>: Abbrev Number: 4 (DW_TAG_pointer_type)
    <4c>   DW_AT_byte_size   : 4
    <4d>   DW_AT_type        : <0x45>
.debug_abbrev:
   4      DW_TAG_pointer_type    [no children]
    DW_AT_byte_size    DW_FORM_data1
    DW_AT_type         DW_FORM_ref4

When removing the above lines:
.debug_info:
 <1><4b>: Abbrev Number: 4 (DW_TAG_pointer_type)
    <4c>   DW_AT_byte_size   : 4
.debug_abbrev:
   4      DW_TAG_pointer_type    [no children]
    DW_AT_byte_size    DW_FORM_data1
Removing the DW_AT_type fixes the issue. I don't know enough about the dmd
backend to create a patch to check if the type is a function pointer or not, so
I can't create a patch, but the patch should be simple if you're familiar with
the DM backend.

Looking at it again, the above isn't the right way to fix it (although it
does)... The DW_TAG_pointer_type should have a DW_AT_type (void for the above
code sample), and the DW_tag_subroutine_type shouldn't have a DW_AT_type (it is
currently set to 0x0). Sorry if this comment doesn't make complete sense, I
kept coming back to it and amending it :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3987



--- Comment #5 from Robert Clipsham <robert@octarineparrot.com> 2010-03-29 15:29:47 PDT ---
Created an attachment (id=593)
Patch for bug 3987

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3987


Robert Clipsham <robert@octarineparrot.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch


--- Comment #6 from Robert Clipsham <robert@octarineparrot.com> 2010-03-29 15:30:18 PDT ---
I've attached a patch that seems to fix this issue.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3987


Robert Clipsham <robert@octarineparrot.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|patch                       |


--- Comment #7 from Robert Clipsham <robert@octarineparrot.com> 2010-03-30 02:03:55 BST ---
The patch I created works for a selection of cases, and fixes the bug mentioned in the bug report, however there are a lot of extremely related issues which it doesn't fix. I've written a preliminary patch which does fix the other issues, unfortunately it causes the debug info output to be incorrect, so it needs more work. The current patch removes the DW_AT_type from the pointer, but to function properly it should remove the DW_AT_type from the function. This is rather difficult to do, as the function does not know its parent type, so cannot know if it is a function pointer and therefore needs to leave out the DW_AT_type. The current patch I'm working on adds another argument to dwarf_typidx() to specify it, it seems a bit hacky though. If anyone has a better idea of how to check if the function's parent type is a pointer, please let me know :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3987


Robert Clipsham <robert@octarineparrot.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch


--- Comment #8 from Robert Clipsham <robert@octarineparrot.com> 2010-03-30 22:31:36 BST ---
Ignoring the above patch, and removing lines 1447 and 1469 (both DW_AT_type) of backend/dwarf.c, fixes this and most of the function pointer related debugging issues, and unlike the attached patch creates the correct debug info (the patch creates debug info that works but isn't the correct way to do it). The only situations it doesn't not fix involve:
----
// T and U can be any type
T function(U function(/*Any args here*/)) funcptr;
----
Where dmd created invalid information for .debug_range, and when attempting to read the debug info both readelf and objdump degfault, gdb continues to DIE. If I cannot fix this issue then this fix should be applied for now, as the situation is still far better than it is currently (debug info for phobos and druntime works, and most apps I've encountered don't use the above).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3987


Robert Clipsham <robert@octarineparrot.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|patch                       |


--- Comment #9 from Robert Clipsham <robert@octarineparrot.com> 2010-04-01 02:44:44 BST ---
Again, the last patch I mentioned is wrong! The correct solution is to only output the DW_AT_type if the type isn't void. I've managed to fix the other issue too, it needs more time to make a proper patch though. The issue is that the DW_TAG_subroutine_type info for the .debug_info section isn't cached, unlike all the other basic types, so when a function pointer parameter is a function pointer, it generates the debug info again before the end of the output for the current DW_TAG_subroutine_type (I probably didn't explain that too well). The solution is to cache the function types, as well as the basic types. This needs to be a bit more advanced though, as the types are combined, so more than a basic array is needed. I haven't tested if structs/classes have the same issue when they are parameters to function pointers, I'll check.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------