[Dwarf-Discuss] D.4 Member Function Example

Mark Wielaard mjw at redhat.com
Tue May 6 02:38:06 PDT 2014


On Tue, 2014-04-22 at 12:11 +0200, Mark Wielaard wrote:
> I was looking at the D.4 Member Function Example and noticed it flags
> member functions that don't return a value with a DW_AT_type pointing to
> a DW_TAG_unspecified_type with name "void". I haven't encountered
> producers that do this and it seems 5.5.7 Member Function Entries imply
> that DW_TAG_subprogram member function DIEs follow the same rules as
> non-member DW_TAG_subprogram function DIEs. Where 3.3.2 says:
> 
>         If the subroutine or entry point is a function that returns a
>         value, then its debugging information entry has a DW_AT_type
>         attribute to denote the type returned by that function.
>         
>         Debugging information entries for C void functions should not
>         have an attribute for the return type.
> 
> Was the example intended to show that a void function that doesn't
> return a value could still have a DW_AT_type and that it should point to
> a "void" DW_TAG_unspecified_type (are there producers out there which
> encode void member functions this way)? Or is it just an unfortunate
> example that doesn't represent the best practice of what the spec
> intended for no return value member functions? I can submit a
> clarification request in that case.

I think it is just an unfortunate example. I have submitted the
following clarification request to http://dwarfstd.org/Comment.php

Subject:  D.4 Member Function Example wrong return type
Name:  Mark Wielaard
Email:  mjw at redhat.com
Section:  D.4  Page:  235
Type:  Clarification

As discussed on the DWARF discuss list:
http://thread.gmane.org/gmane.comp.standards.dwarf/142 The D.4 Member
Function Example flags member functions that don't return a value with a
DW_AT_type pointing to a DW_TAG_unspecified_type with name "void". This
is wrong because the functions don't actually return a "void", they
don't return a value at all and so according to section 3.3.2 they
should not have a DW_AT_type at all. Suggested change: In Figure 59.
Member function example: DWARF description remove the
DW_AT_type(reference to 1$) from the 7$, 10$ and 12$ DW_TAG_subprograms
for func1, func2 and func3.




More information about the Dwarf-Discuss mailing list