Issue 050711.2: Add DW_AT_object_pointer for "this" parameters
Section: 5.6.7
PROPOSAL:
Add a DW_AT_object_pointer attribute to Dwarf 3 and
require it to be added to the appropriate DW_TAG_formal_parameter
die in languages that have a "this" or a "self" pointer that
is passed as a function parameter.
See issue : 040511.1 Static Member Function
Also see the minutes for the con-call of June 28, 2005
This doesn't invalidate the recent additions that require
the "this" formal parameter to be marked "const" for const
members, and marked as artificial. Those are
still required. If the new attribute is used, then
the parameter would not need to be first, or named
with any special name.
Some of what we added recently would move to an italics
section describing what implementations do when they
don't use DW_AT_object_pointer. Specifically the
special name, and the required position in the list.
If this proposal is generally accepted, I'll write up the exact
wording and send it to the alias.
Notes:
I'll remind everyone that we accepted Mathhew's proposal.
I think what we already have is a workable solution to
the problem. But I think we can do better.
I don't like the idea of requiring special parameter names
to denote special semantics. Function declarations in my
compiler don't usually have parameter names. Our compiler
will need to attach that name as special case. If we
want to denote some special semantics for one particular
parameter, the right way to do that is to use an attribute.
Making this change doesn't cause any dwarf generators to
be "non-compliant" because none of them can be dwarf 3
compliant until we standardize the spec. Until then, they are
"dwarf 2 with extensions".
I wouldn't worry that adding DW_AT_object_pointer will cause
any dwarf readers to immediately rush off and remove support
for compilers that don't emit the new attribute. 1) I don't
think that's going to happen. 2) I don't think it's our
problem to worry about, it's a quality of implementation issue.
================================================
Revised proposal:
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.
*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.*
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."
===================================
Revised proposal accepted with following modifications:
Replace "die" with "debug information entry".
Replace "DW_AT_sunprogram" with "DW_AT_subprogram".
