DWARF Standard


HOME
SPECIFICATIONS
FAQ
ISSUES



100423.1 David Anderson Abstract root clarification Editorial Accepted


Section 3.3.8.1, pg 59

Background:
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
needs clarification.

Example:
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
...
<2><77027>      DW_TAG_class_type
               DW_AT_name                  RtX
               DW_AT_declaration           yes(1)
...
<3><77611>      DW_TAG_subprogram // A public class member function.
                  //  A Constructor in this case.
               DW_AT_name                  RtX
               DW_AT_MIPS_linkage_name          mangledRtX (a mangled name)
               DW_AT_declaration           yes(1)
               DW_AT_external              yes(1)
               DW_AT_accessibility         DW_ACCESS_public
...
Global subprogram ZED definition begins here, CU scope.
...
lexical block begin
...
<4><887217>     DW_TAG_inlined_subroutine // concrete inlined instance
               DW_AT_abstract_origin       <887268>
               DW_AT_low_pc                0x4061044
               DW_AT_high_pc               0x4061084
<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.)
               DW_AT_inline                DW_INL_declared_inlined
...
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
   DW_AT_inline DW_INL_declared_inlined
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 "3.3.8.1 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.
"





All logos and trademarks in this site are property of their respective owner.
The comments are property of their posters, all the rest © 2007-2017 by DWARF Standards Committee.