||Abstract root clarification
Section 220.127.116.11, pg 59
A commercial compiler emits DWARF as in the following example
which leaves a consumer unable to properly handle inlined
functions. Yet the compiler does not clearly violate
anything in DWARF3 or DWARF4. So it seems the standard
The compiler author provides no tie from
the concrete inlined instance through the abstract root back
to the class member! See comments at the end of this note.
The abstract root below is generated in the lexical context of
the inlined subroutine, not in the class declaration.
If the abstract root were in the class declaration
there would be no ambiguity.
The source was coded in C++ .
I am faking the mangled name here, the mangledRtX string
is shorter and easier to read than the original mangled name!
CU scope begins here
<3><77611> DW_TAG_subprogram // A public class member function.
// A Constructor in this case.
DW_AT_MIPS_linkage_name mangledRtX (a mangled name)
Global subprogram ZED definition begins here, CU scope.
lexical block begin
<4><887217> DW_TAG_inlined_subroutine // concrete inlined instance
<4><887268> DW_TAG_subprogram // Abstract root
DW_AT_name mangledRtX (The same
mangled name as above.
It is a mistake using a mangled
name here, it is a compiler bug.)
end subprogrogram ZED
I don't find any clear language in DWARF3 or 4 which tells a compiler implementor
that it's necessary to either have the abstract root be in the class RtX or else
provide a tie (like DW_AT_specification) to tie the abstract root to the declaration
of the class member at 77611.
In the example above the compiler could have added a new attribute to 77611 such as
and referred to 77611 as the abstract root instead of constructing a duplicate.
Proposed specification change based on public review draft of DWARF4:
Add the following after the first paragraph of "18.104.22.168 Abstract Instances".
"Each abstract instance root should either be part of a larger tree (thus
giving a context for the root) or should use DW_AT_specification to refer to the
declaration in context.
For example, in C++ the context might be a namespace declaration or a class declaration.