Issue 050720.2: DW_AT_object_pointer (v2)

Author: Chris Quenelle
Champion: Chris Quenelle
Date submitted: 2005-07-20
Date revised:
Date closed:
Type: Enhancement
Status: Closed - Duplicate
DWARF Version: 3
Section: 5.6.7

BACKGROUND:

There is no explicit way to know if a C++ member function
is declared static or const.  Both of these properties can
be deduced in a straight forward way if the dwarf consumer
can identify whether the function has a "this" pointer
and if that pointer is a "const" pointer.  The same
problem applies to other languages (Objective C/C++).

Based on a recent addition, dwarf 3 requires that the
"this" pointer (if preset) must be the first DW_TAG_formal_paremeter
child of the DW_TAG_sunprogram die, and it must have the
name "this" (or "self" if that's appropriate for the language).

We should be more explicit about marking the "this" parameter.
If the pointer is marked explicitly there would be no need
for an artificial restriction on ordering or naming.

For more background see issue : 040511.1  Static Member Function
Also see the minutes for the con-call of June 28, 2005
which were sent to the dwarf-workgroup alias.

I didn't create an example for this, but I can do that
if people think it's appropriate.

PROPOSAL:

Add an attribute DW_AT_object_pointer which is a reference
to a die representing the object pointer for this function.

In section 5.6.7:
 append to the end of the section:

  For member functions which are not static, the DW_AT_object_pointer
  attribute is used on the DW_TAG_subprogram to specify the "this"
  pointer (for C++) or the "self" pointer (in Objective C/C++).
  Often, this attribute will point to a DW_TAG_formal_parameter
  die, but it may also point to a variable die.

  <italics>
  In older implementations where DW_AT_object_pointer is not used,
  one of the parameters should be named "this", and should appear
  first in the list of parameters.
  </italics>

  The object pointer isn't explicitly declared in the source code,
  so the die that represents the object pointer should be marked
  with the DW_AT_artificial flag.

  If the DW_AT_type for an object pointer points to a "const" qualified
  type, then the member function was declared as "const" in the source code.

  If the DW_AT_type for an object pointer points to a "volatile" qualified
  type, then the member function was declared as "volatile" in the source code.

(I'll leave the list of table updates to the editor.  It will
be similar to the DW_AT_explicit proposal, for example.)

-------------------------

So that people can compare my proposal with what was
previously suggested on the alias, I've copied some
paragraphs from previous emails so you can compare.

Ron previously suggested the following wording:

    "If the member function entry describes a non-static member
    function then that entry owns at least one formal parameter
    entry. The first such formal parameter entry
    corresponds to the object for which the function is called.
    The name attribute of that first formal parameter is defined by
    the current language (for example <code>this</code> for C++ or
    <code>self</code> for Objective-C++ and some other languages).
    The parameter also has a DW_AT_artificial attribute whose value
    is true. Conversely, if any of these properies does not apply
    then the member function entry describes a static member function.

    "If the member function entry describes a <code>const</code>
    non-static member function, then the entry describes a non-static
    member function whose first formal parameter entry has a type
    that is const qualified.

    *For simplicity, the type of the first formal parameter
    of a non-static member function need not be checked by a
    consumer to confirm that it is a pointer to the parent
    class or a const qualified variant thereof.

Matt previously suggested:

    "If the member function entry describes a non-static member function
    that has a const-volatile qualification, then the entry describes a
    non-static member function whose first formal parameter has a type
    that has an equivalentl const-volatile qualification."

=======================================

Duplicate issue -- see 050711.2*